Port to the Parley cursor rework

[DJMcNab]

The upstream PR has now been merged: linebender/parley#170

I've had to add a hack to workaround linebender/parley#186. This occurs because of the first pass of layout with zero available area.

[DJMcNab]

FYI @dfrg it seems like something has changed with line height? Is this expected.

[dfrg]

I didn’t change individual line height but updated the overall layout dimensions to use the max_coord of each line so that the layout box encompasses the full text. There’s obviously something funky going on with how line metrics are calculated because these should be the same but the web compatible line height changes added some complex interactions and I haven’t had time to investigate that.

[DJMcNab]

Hmm. I've just done some quick testing, and descenders still seem to be cut off when clipping to the layout box. See also https://xi.zulipchat.com/#narrow/channel/205635-text/topic/Some.20funny.20typography.20with.20Masonry

The descenders being cut off is:

[DJMcNab]

Note for reviewers: These changes are only ports of changes done in linebender/parley#170, except for the set_width hack

[mwcampbell]

My quick accessibility tests are all working.

[mwcampbell]

Wrote too soon. I just caught two accessibility bugs that were probably actually introduced in #616:

1. The text area doesn't have the read only flag set if it's non-editable, like the multi-line document in the mason example.
2. When calling PlainEditor::accessibility or LayoutAccessibility::build_nodes, the X and Y offsets need to be in window coordinates, with the scale factor applied, like the bounding rectangles that are set by the Masonry widget infrastructure. Perhaps this could be documented more clearly in AccessKit or Parley.

[DJMcNab]

The text area doesn't have the read only flag set if it's non-editable, like the multi-line document in the mason example.

Ouch... that's a really embarrassing mistake. I think this was #754

Thanks for the clarification on point 2. I think a tiny bit of documentation would be good.

[mwcampbell]

Looks like I need to modify Parley to take the scale factor into account when calculating the run bounding rectangles and character widths for AccessKit.

[mwcampbell]

Alternatively, I could eliminate the need to apply the scale factor to individual node bounding rectangles, which would complicate the Parley API, if I instead modify Masonry to set an AccessKit transform on the root node.

[DJMcNab]

if I instead modify Masonry to set an AccessKit transform on the root node.

I think that would be the idiomatic way within the current form of Xilem (there is a future question about pixel alignment)...

[mwcampbell]

OK, let's land #764, then rebase this, and then you won't need to include the scale factor when calculating the x and y offsets.

[tomcur]

I'm able to edit the text of Prose through selection and space, but I don't think that's an issue introduced here.

[mwcampbell]

Now my quick accessibility tests all pass.