1946552 - Windows Narrator draws bounds one character too far into next unit

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. Launch Windows Narrator
3. Open test page data:text/html,abc def ghi
4. Navigate by character or word and observe the bounds that Narrator draws on-screen

Expected: The bounds will tightly bound the spoken range, as it does in Edge.
Actual: The bounds tightly bound the spoken range on the left hand side (assuming LTR text), but extend one character/word/etc. past on the right hand side.

The utterances are not incorrect, they just don't match the bounded text. I suspect that the "too far to the right" behavior occurs due to some particularity in our implementation of UIA TextUnits combined with how we render bounds to UIA, since it's one character or one word too far (corresponding to TextUnits), based on the way you navigate with Narrator.

Comment 1

[Nathan LaPré]

Attachment: Bug 1946552: Fix problems and inconsistencies in the calculation of text bounds for a range.

In certain conditions, WalkLineRects uses the incorrect endpoint for
calculating rects for a given TextLeafRange. This revision fixes the problem by
properly walking the endpoint back by one character, if possible.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0a39b47ae3c2
Fix WalkLineRects endpoint calculation, r=Jamie

Comment 3

[Sandor Molnar[:smolnar]]

Backed out for causing mochitest failures @ accessible/tests/browser/bounds/browser_test_zoom_text.js & browser_caching_text_bounds.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/25362b7d21e2dff3aecbc7c67e993acf7a61ed0f

Push with failures

Failure log -> TEST-UNEXPECTED-FAIL | accessible/tests/browser/e10s/browser_caching_text_bounds.js | Wrong width of text between offsets

Failure log -> TEST-UNEXPECTED-FAIL | accessible/tests/browser/bounds/browser_test_zoom_text.js | Wrong width of text between offsets

Comment 4

[Nathan LaPré]

Seems I've largely broken getting the bounds of non-LTR text here. Looking into a fix.

Comment 5

[Nathan LaPré]

The specific test that this change breaks is this one. There are others also broken, but I think they're fixed by the patch for Bug 1947331. :Jamie intends to pick up this work once I'm gone.

Comment 7

[James Teh [:Jamie]]

I'm merging bug 1947331 into this, as the changes in these two bugs are somewhat intertwined and I need to make significant changes to how these bounds functions behave. STR from that bug:

1. Turn on UIA support in about:config; set accessibility.uia.enable to true.
2. Launch Windows Narrator
3. Open site data:text/html,This is the first sentence<br/>This is the second sentence, which is longer than the first
4. Navigate by word (Narrator + l) through the first sentence until you hit the last word, "sentence."
5. Observe the bounds wrapping the word.

Expected: The drawn bounds wrap the word "sentence" exactly, as they do in Edge.
Actual: The drawn bounds don't bound the word "sentence." They seem to extend from the top of the first line to the bottom of the second line vertically, but don't properly bound the word "sentence" horizontally on either side of the word.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f99db37efb0a
Fix problems and inconsistencies in the calculation of text bounds for a range. r=morgan

Comment 9

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/f99db37efb0a

Comment 10

[BugBot [:suhaib / :marco]]

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.
• If no, please set status-firefox137 to wontfix.

For more information, please visit BugBot documentation.