1876150 - VO cannot reach right-most address bar buttons

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Morgan Reschenberg [:morgan]]

STR:

1. Enable VO
2. Focus the refresh button by VO+next / VO+shift+next navigating into the toolbar group
3. Use VO+next to attempt to reach the bookmark button for the current page

Expected:
VO focuses the bookmarks button

Actual:
VO crashes OR VO throws focus to the first focusable element in web content once it reaches the main editable field of the address bar

Workaround:
Use the tab key to move VO focus (with "keyboard focus moves VO focus" checked in the VO Utility settings). This works as expected

Comment 1

[Morgan Reschenberg [:morgan]]

mozregression gives me https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e9cfa3b4b369a61aa06f1e4db07aa64571c6dc08&tochange=e9bad808b74cf1b84601ededed2f4dbf63a6d115

setting regressing bug accordingly

Comment 2

[Eitan Isaacson [:eeejay]]

wow, thanks. sorry.

Comment 3

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

Set release status flags based on info from the regressing bug 1846312

Comment 4

[Eitan Isaacson [:eeejay]]

The awesomebar has a collapsed menu integrated into it (the combo auto-suggest UI). When we VO arrow past it, VO encounters an AXAttachement for this collapsed menu. This is very unique to XUL where we expose in our tree not displayed element with the INVISIBLE state. VO, anyhow doesn't know what to do at this point and crashes.

This is a tough bug to fix. I can think of several ways to do this, nothing ideal:

1. Fix our TextLeafRange's LeafRule to not go into collapsed menubuttons/invisible content. This is hard because we can still get into bad states. For example, the TextLeafPoint constructor needs to be changed to not go into deepest child unconditionally. This is a lot of changes for a mac quirk.
2. Adjust-up the AXAttachements when encountering invisible content. This too isn't ideal because we don't know if we are adjusting up into a container or a sibling in relation to the text run.
3. Don't support text marker API in chrome. We currently rely on this API for all of our caret/selection events. I think there might be repercussions if we just pull support here.
4. Prune INVISIBLE children from XUL trees. I thought I did that at some point because it caused a lot of pain for mac, but maybe I didn't?

I think I would go for option 1 or 4, but I don't love any of them. Asking Jamie for input too, because he is the text maven, XUL lover.

Comment 5

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #4)

The awesomebar has a collapsed menu integrated into it (the combo auto-suggest UI). When we VO arrow past it, VO encounters an AXAttachement for this collapsed menu.

Isn't AXAttachement to do with text ranges? Why is VO looking at the text range for the combo box when the combo box isn't editable?

3. Don't support text marker API in chrome. We currently rely on this API for all of our caret/selection events. I think there might be repercussions if we just pull support here.

That's true, but as above, could we just support it on editable content? It seems weird for VO to care about text ranges on the non-editable combo box anyway.

4. Prune INVISIBLE children from XUL trees. I thought I did that at some point because it caused a lot of pain for mac, but maybe I didn't?

Most invisible XUL elements (tooltips, panels) were pruned from the tree, but menupopups turned out to be trickier. We have bug 1703899 for that. I think we do want to do this in general anyway, so this could tackle multiple problems, but it's still going to be tricky.

Comment 6

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

Set release status flags based on info from the regressing bug 1846312

Comment 7

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1876150 - Filter out collapsed XUL menus when concatinating text ranges. r?morgan

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae92b57ec3bb
Filter out collapsed XUL menus when concatinating text ranges. r=morgan

Comment 9

[Cristian Tuns]

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

Comment 10

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

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

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox125 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Eitan Isaacson [:eeejay]]

Comment on attachment 9392622 [details]
Bug 1876150 - Filter out collapsed XUL menus when concatinating text ranges. r?morgan

Beta/Release Uplift Approval Request

• User impact if declined: VoiceOver crashes when user uses cursor in address bar.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: * Enable VO
• Focus the refresh button by VO+next / VO+shift+next navigating into the toolbar group
• Use VO+next to attempt to reach the bookmark button for the current page

Expected:
VO focuses the bookmarks button

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This changes how we return strings and calculate text offsets. It should only be limited to embedded XUL menus which we don't have a lot of.
• String changes made/needed:
• Is Android affected?: No

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9392622 [details]
Bug 1876150 - Filter out collapsed XUL menus when concatinating text ranges. r?morgan

Approved for 125.0b5.

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/26c03168b524

Comment 14

[Ciprian Georgiu, Desktop QA]

I have reproduce this issue using Firefox Beta 125.0b4, under macOS 13 with STR from comment 0.

The issue is verifed as fixed on Beta 125.0b5 and latest Nightly 126.0a1.