1816601 - [CTW] Consider emulating HyperTextAccessible::OffsetAtPoint returning 0 even if offset 0 isn't at the given point

Status: RESOLVED FIXED

(Core :: Disability Access APIs, enhancement)

Description

[James Teh [:Jamie]]

Spun off bug 1809082 comment 3.

data:text/html,<button><div style="display: flex;"><div style="width: 100px; background-color: red;" role="none"></div>test

If you mouse over the red area, Firefox without cache + NVDA reports "test", but Firefox with cache does not. If you mouse over the text, "test" is reported regardless of the cache. Chromium browsers are consistent with Firefox with cache.

Although this intuitively seems like ideal behaviour in Firefox without cache, it's actually due to a bug which is fixed by CTW . NVDA mouse tracking is designed to read text, not controls. It asks for the character at the position of the mouse. Firefox without cache incorrectly reports the first character, when in reality, there is no character there (because it's not text). The same behaviour can be observed in other browsers too. Perhaps NVDA should report the control if there is no character directly under the mouse, but it doesn't at this stage.

I think this behaviour without the cache occurs because of this code in HyperTextAccessible::OffsetAtPoint. If the point is smaller (both x and y) than the child's width/height, we assume we've found the right frame. We do call nsIFrame::GetContentOffsetsFromPointExternal to get the offset, but I'm guessing it must return 0 as well, though I haven't verified that. There does seem to be some fuzziness in layout when querying a point near the edge of a frame which might explain this.

This fuzziness is clearly biased to the top left. Otherwise, the point would always be larger than the width/height of all frames, so we'd keep searching.

The question is whether we want to emulate this bug with CTW. Doing that would mean that hit testing an icon that isn't in the a11y tree and is positioned to the left of text will report the text. Also, it will work around LinkedIn's awful pattern of hiding the visual text with ARIA and having a visually hidden alternative right next to it:

data:text/html,<a href="https://example.com/"><span aria-hidden="true">aria-hidden</span><span style="display: block; position: absolute; clip: rect(0 0 0 0); width: 1px; height: 1px; overflow: hidden;">visually-hidden</span></a>

If we are going to do this, we'll need to do it in HyperTextAccessibleBase. TextLeafPoint isn't inherently restricted to containers like HyperText is, so it's more difficult to fuzz in that case. Also, we should probably keep the TextLeafPoint API fairly clean and restrict the hacks to higher level callers. :)

Comment 1

[James Teh [:Jamie]]

We should be able to implement this bug by replacing this block with something like this:

if (coords < point.CharBounds().TopLeft()) {
  // Appropriate comment about this horrible hack here
  return 0;
}

Comment 2

[James Teh [:Jamie]]

Attachment: Bug 1816601: HyperTextAccessibleBase::OffsetAtPoint: Return 0 if the point is within the container but before the rect at offset 0.

This perpetuates a bug in (local) HyperTextAccessible that some users have unfortunately come to rely on.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/95d948d14dfe
HyperTextAccessibleBase::OffsetAtPoint: Return 0 if the point is within the container but before the rect at offset 0. r=nlapre

Comment 4

[Cosmin Sabou [:CosminS]]

Backed out for causing mochiest failures on browser_test_text.js.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=D7Hc6tC4RKC4El43WEDFFg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=95d948d14dfe58ebb1ac3a2c7d5c500dae22b6b6

Failure log: https://treeherder.mozilla.org/logviewer?job_id=405812254&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/78ebe9f9b290c9e44a6ae84b3182ea21cbfac01a

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fbb7ce70797d
HyperTextAccessibleBase::OffsetAtPoint: Return 0 if the point is within the container but before the rect at offset 0. r=nlapre

Comment 6

[Marian-Vasile Laza]

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

Comment 7

[James Teh [:Jamie]]

Comment on attachment 9317612 [details]
Bug 1816601: HyperTextAccessibleBase::OffsetAtPoint: Return 0 if the point is within the container but before the rect at offset 0.

Beta/Release Uplift Approval Request

• User impact if declined: Screen readers won't report content under the mouse correctly in some cases when the accessibility cache is enabled via a release experiment.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Covered by tests. Only impacts screen coordinates reported to accessibility clients when the accessibility cache is enabled.
• String changes made/needed:
• Is Android affected?: No

Comment 8

[Donal Meehan [:dmeehan]]

Comment on attachment 9317612 [details]
Bug 1816601: HyperTextAccessibleBase::OffsetAtPoint: Return 0 if the point is within the container but before the rect at offset 0.

Approved for 111.0b5

Comment 9

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/cb5e0668eb9b