1948149 - Crash in TextRange::CommonParent with NVDA on, UIA enabled [@ mozilla::a11y::TextRange::CommonParent ]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Nathan LaPré]

Crash report: https://crash-stats.mozilla.org/report/index/0ed365f3-018f-4ca2-9390-59ad30250213

STR:

1. Start or restart the browser with UIA enabled (in about:config, set accessibility.uia.enable to true)
2. Turn on NVDA.
3. Ctrl + t to open a new tab, start typing something. For instance: about:config.

Expected: Typing doesn't crash the browser in this situation.
Actual: Partway through typing, the browser crashes.

cc :Jamie, I think this is potentially related to recent changes in CroppedSelectionRanges since that new code is implicated in this call stack. Not sure if this is something that change introduced or not. Also: maybe this is something that can only happen with NVDA on Firefox UIA, but I'm inclined to fear it could happen with other IA2 ATs, too.

Comment 1

[James Teh [:Jamie]]

(In reply to Nathan LaPré from comment #0)

cc :Jamie, I think this is potentially related to recent changes in CroppedSelectionRanges since that new code is implicated in this call stack. Not sure if this is something that change introduced or not.

It's possible, though I've also seen intermittent crashes before when typing into the address bar, so I suspect it's a bug that's been lurking for a while.

Also: maybe this is something that can only happen with NVDA on Firefox UIA, but I'm inclined to fear it could happen with other IA2 ATs, too.

NVDA is using native UIA in this case. I've submitted a PR to force disable UIA for Firefox, but that hasn't been reviewed yet.

Comment 2

[James Teh [:Jamie]]

Looking into this.

Comment 3

[James Teh [:Jamie]]

(In reply to Nathan LaPré from comment #0)

cc :Jamie, I think this is potentially related to recent changes in CroppedSelectionRanges since that new code is implicated in this call stack.

For completeness, I double checked by reverting the patch for bug 1825618. The crash still occurs. That said, I have a fix locally.

Comment 4

[James Teh [:Jamie]]

Attachment: Bug 1948149: HyperTextAccessible::DOMPointToOffset: For a text node, constrain the offset to the length of the TextLeafAccessible.

Sometimes, text in the accessibility tree can be out of date with DOM briefly because the accessibility engine updates text asynchronously.
When this happens, DOMPointToOffset can be called on a text node with an offset which is valid for DOM, but not yet valid for accessibility.
Previously, we ended up producing an invalid HyperText offset, causing a crash.
The best we can do in this case is gracefully constrain the offset to the text in the accessibility tree.

In the scenario in this bug report, the user was typing into the address bar.
The address bar added and selected text due to an autocomplete suggestion.
After the DOM update but before the accessibility tree was updated, a UIA client queried the selection.
Since selection is retrieved from DOM, this resulted in an offset that didn't exist in the accessibility tree.
Now that the offset is constrained, this will no longer result in a crash.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b7e7c18d3113
HyperTextAccessible::DOMPointToOffset: For a text node, constrain the offset to the length of the TextLeafAccessible. r=nlapre

Comment 6

[Atila Butkovits]

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