1557849 - Missing accessibility events and wrong role when context menu for address bar appears

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Launch Firefox and Accerciser
2. In Accerciser, enable event monitoring of "window" and "object:state-changed" events for firefox
3. Give focus to Firefox's address bar (in the URL entry)
4. Press Shift+F10

Expected results: An object:state-changed:showing event for an object with role menu and/or a window event for a window whose child is a menu.

Actual results: An object:state-changed:expanded event for an object with role combo box. In addition, this combo box happens to lack state focused.

Impact: Orca says nothing when the user presses Shift+F10 from the address bar.

Notes:

1. If you bring up a context menu from the body of the document or from within Thunderbird, we get the correct events and roles.
2. The expanded event isn't 100% wrong; but it's certainly not right. For one thing, a context menu isn't a combo box. So the role is wrong. For another thing it lacks state focused and never claims focus. Orca doesn't present events for things the user isn't in, and which don't look definitively like what they are. Having the expected results as stated above would resolve these issues.

Thanks in advance!

Comment 1

[James Teh [:Jamie]]

Thanks for filing. The same underlying issue also causes this context menu to be reported as a list on Windows.

I think this happens because we have logic to treat a XUL menupopup inside a combo box as a combo box list, which is necessary to get the correct behaviour across platforms for expanded combo boxes:
https://searchfox.org/mozilla-central/rev/ee806041c6f76cc33aa3c9869107ca87cb3de371/accessible/xul/XULMenuAccessible.cpp#401
However, that code doesn't differentiate between a menupopup which serves as the combo box list and a menupopup which serves as a context menu. I'm not sure how it can differentiate between these two things, but I think that's the challenge we need to solve here.

Comment 3

[James Teh [:Jamie]]

Raising this to p2, since users might think there's no context menu at all when they press shift+f10 and nothing happens. Also, reporting it as a list on Windows is just weird.

Comment 4

[James Teh [:Jamie]]

Implementation thought: I'm not sure, but I think the context menupopup might be associated with a context or contextmenu attribute. Can we use this to make the determination?

Comment 5

[Morgan Reschenberg [:morgan]]

Huh: not sure if this is related, but when I try to use the browser toolbox to inspect the context menu (right-click on URL bar chrome) I get the following error:

[Parent 81039, Main Thread] ###!!! ASSERTION: XULMenupopup doesn't have INVISIBLE when it's inactive: 'isActive || (state & states::INVISIBLE)', file /Users/mraereschenberg/test-moz/accessible/xul/XULMenuAccessible.cpp, line 373

Is this the same problem? That the context menu isn't exposed to the accessibility tree?
How can there be an incorrect role/action if the object is invisible? [maybe "invisible" isn't the right word here, seeing as the error message says it doesnt have invisible? not sure what that means...]

Comment 6

[James Teh [:Jamie]]

As discussed, I think what's happening here is that the option to make popups sticky means that the menu is inactive, but still visible. That's not something that should happen in normal usage, but I guess this code was written before (or just didn't account for?) this sticky popup thing. Ultimately (whether in this bug or elsewhere), I think we should convert that assertion to a warning. For now, you could test with it commented out. In any case, it's not related to this bug as such, more a (broken) artefact of the way you're testing.

Comment 7

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1557849: Check if a MenuPopupAccessible belongs to a context menu to determine its role assignment.

Comment 8

[Morgan Reschenberg [:morgan]]

Windows tested with NVDA:

• When launching a context-menu on the url bar, NVDA announces "menu"
• NVDA no longer reports "list" when navigating the context menu.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8f8c95389f9c
Check if a MenuPopupAccessible belongs to a context menu to determine its role assignment. r=Jamie

Comment 10

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/8f8c95389f9c

Comment 11

[Daniel Bodea [:danibodea]]

I am attempting to verify this fix, but I am having trouble reproducing it. Please answer some question and keep in mind the fact that I am no developer:

1. Is this an issue for the Linux environment? Or all?
2. Where can I get that "Accerciser" and how do I install it?
3. Do I need an 'Accerciser" tutorial to perform the rest of the steps written in comment 0?

Otherwise, you could help us verify the fix in all the channels needed:

• Nightly: http://archive.mozilla.org/pub/firefox/nightly/2019/12/2019-12-03-09-48-30-mozilla-central/
• Beta: http://archive.mozilla.org/pub/firefox/releases/72.0b1/
• Latest Release version also.

Thank you for your contribution!