1951833 - Windows Text Cursor Indicator disappears on blank input lines

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Nathan LaPré]

STR:

1. Turn on UIA support in about:config; set accessibility.uia.enable to true.
2. Turn on the Windows Text Cursor Indicator (Settings -> Accessibility -> Text Cursor -> Set Text cursor indicator to "On")
3. Open test page data:text/html,<textarea>ABC%0A%0A%0ADEF</textarea>
4. Focus the textarea and move the insertion cursor to the second line (the first blank line)

Expected: The insertion cursor and the Windows Text Cursor Indicator are at the same place. The Text Cursor Indicator is present.
Actual: The Text Cursor Indicator is absent.

This works in Edge. If there is only one blank line between text lines, the Text Cursor Indicator does not disappear (though it may be on the incorrect line). This is also broken on the IA2 -> UIA bridge.

Comment 1

[James Teh [:Jamie]]

Findings:

1. We previously learned that line feed characters in pre-formatted text return 0 rects (bug 1945036, bug 1946552). However, it turns out that in the cache, even though they have 0 width, they have a valid x, y and height. We just refuse to use the rect at all if it's empty.
2. Line feed characters generated by <br> also seem to return 0 rects. These don't have character bounds in the cache. However, the bounds returned by Accessible::Bounds() have a valid x and y, but usually a 0 width and height. We might need special code in CharBounds to use Bounds() for this case.

Comment 2

[James Teh [:Jamie]]

contentEditable version of this problem (as seen in Gmail):

data:text/html,<div contenteditable role="textbox"><div>a</div><div><br></div><div><br></div><div>b</div></div>

Comment 3

[James Teh [:Jamie]]

The approach I'm considering to fix the <br> case might also fix HTML <li> bullets (or a similar fix might be possible).

Comment 4

[James Teh [:Jamie]]

Attachment: Bug 1951833 part 1: Support line feed characters in TextLeafPoint::CharBounds.

Previously, both literal line feed characters in pre-formatted text and HTMl <br> elements returned a rect with 0 width and/or height.
Because of the way CharBounds() was implemented, this also returned 0 for x and y.
This caused problems for clients such as Windows Text Cursor Indicator which need the rectangle for the character at the caret.
Now, we return the correct x and y coordinates.
We also return a minimum width and height of 1 to ensure clients treat it as an actual rectangle.

Aspart of this, CharBounds() has been refactored slightly for consistency and readability.
As a bonus, this also fixes character bounds for list item bullets (bug 360003), but a test for that will be added in a subsequent patch.

This patch also removes the special case line feed code added to TextLeafRange::WalkLineRects() in bug 1946552, since CharBounds() now handles this.

Comment 5

[James Teh [:Jamie]]

Attachment: Bug 1951833 part 2: Make ITextRangeProvider::GetBoundingRectangles return a rectangle for a collapsed range.

Comment 6

[James Teh [:Jamie]]

Hi Morgan. Would you mind taking this try build for a spin, testing as per the steps outlined in comment 0? Hopefully, this build (which includes the patches here) actually does fix the bug. Notes:

1. You don't need to set accessibility.uia.enable; it's now enabled by default (and it's a number, not a boolean now).
2. In step 2, "Settings" refers to Windows Settings; Text Cursor Indicator is a Windows AT.

Thanks!

Comment 7

[James Teh [:Jamie]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=24f41e0062f6ae0101252561232be00a7eee0ca4

Comment 8

[Morgan Reschenberg [:morgan]]

(In reply to James Teh [:Jamie] from comment #6)

Hi Morgan. Would you mind taking this try build for a spin, testing as per the steps outlined in comment 0? Hopefully, this build (which includes the patches here) actually does fix the bug. Notes:

1. You don't need to set accessibility.uia.enable; it's now enabled by default (and it's a number, not a boolean now).
2. In step 2, "Settings" refers to Windows Settings; Text Cursor Indicator is a Windows AT.

Thanks!

Hey! Tested per Nathan's instructions in your linked try build. The issue this bug was filed for seems resolved; I can use the text cursor indicator in tandem with the insertion cursor (they overlap and behave correctly on the two newlines between ABC and DEF in the data:text/html example given).

If I add two more newlines after DEF in the textarea example, however, the windows text cursor indicator will only navigate to the first of the two newlines. The text insertion cursor will move to the final newline, leaving the text cursor indicator behind.

Also, the content editable example you gave above doesn't seem to work. I can see the text cursor indicator inside the editable area when I first click to focus the area (e.g. if I initially click at the newline below a, the text cursor indicator shows there). However if I use arrow keys to move around as I normally would, the text cursor indicator goes away and only the insertion cursor is shown. When I click outside of the content editable, the text cursor indicator is shown at the end of the content editable (after b) regardless of the last place I clicked within the text.

Are there other examples you'd like me to try to narrow down the issues here?

Comment 9

[James Teh [:Jamie]]

(In reply to Morgan Reschenberg [:morgan] from comment #8)

Hey! Tested per Nathan's instructions in your linked try build.

Thank you.

The issue this bug was filed for seems resolved; I can use the text cursor indicator in tandem with the insertion cursor (they overlap and behave correctly on the two newlines between ABC and DEF in the data:text/html example given).

Excellent!

If I add two more newlines after DEF in the textarea example, however, the windows text cursor indicator will only navigate to the first of the two newlines. The text insertion cursor will move to the final newline, leaving the text cursor indicator behind.

Ug, yeah, looking at it, I can totally see why that would be. I thought bug 1966812 was just a nice-to-have, but it looks like we'll actually need it.

Also, the content editable example you gave above doesn't seem to work. I can see the text cursor indicator inside the editable area when I first click to focus the area (e.g. if I initially click at the newline below a, the text cursor indicator shows there). However if I use arrow keys to move around as I normally would, the text cursor indicator goes away and only the insertion cursor is shown.

Drat. I think I know why that might be happening. Would you mind testing with accessibility.uia.enable set to 0 in about:config? I suspect this one is a regression, in which case it's a UIA ship blocker.

Are there other examples you'd like me to try to narrow down the issues here?

I think I'll have more for you as I file more bugs to deal with these edge cases. Sorry; there might be some back and forth here. :)

Comment 10

[Morgan Reschenberg [:morgan]]

Drat. I think I know why that might be happening. Would you mind testing with accessibility.uia.enable set to 0 in about:config? I suspect this one is a regression, in which case it's a UIA ship blocker.

setting the pref to 0 makes this work :)

Comment 11

[James Teh [:Jamie]]

Yippee! Ship blocker! 😢 Thanks for testing.

Comment 12

[James Teh [:Jamie]]

The issue this bug was filed for seems resolved

Given this, I'm going to address the remaining issues here in separate bugs, rather than overloading this one.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/669220a3458a
part 1: Support line feed characters in TextLeafPoint::CharBounds. r=morgan
https://hg.mozilla.org/integration/autoland/rev/327aa1eaa276
part 2: Make ITextRangeProvider::GetBoundingRectangles return a rectangle for a collapsed range. r=morgan

Comment 14

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/669220a3458a
https://hg.mozilla.org/mozilla-central/rev/327aa1eaa276

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.