1281828 - Context menu accessibility broken, first level no longer accessible to screen readers

Status: RESOLVED WORKSFORME

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

Description

[Marco Zehe (:MarcoZ)]

Regression in 2016-06-23 nightly build.

0. Run Firefox and NVDA.
1. Focus any link.
2. Hit the Applications Key or Shift+F10.

Expected: NVDA should say menu, and hitting up and down arrows then should speak the menu items.
Actual: Silence from NVDA.

3. Hover the mouse over a sub menu, like "Open link in container tab".

Result: Sub menu opens, menu speaks with NVDA.

4. Press left arrow to back out of that sub menu.

Result: Silence again, or worse, NVDA thinks we've dropped out of that menu and are now in the virtual buffer again.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=51377a64158941f89ed73f388ae437cfa494c030&tochange=c9edfe35619f69f7785776ebd19a3140684024dc
Prime suspect is bug 1274381, which landed during that window.

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, if you can't take care of this before vacation, I'll have sheriffs back out and reopen suspected bug 1274381.

Comment 2

[alexander :surkov (:asurkov)]

Do I understand right that bug 1274381 has been confirmed as a regression?

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #2)
> Do I understand right that bug 1274381 has been confirmed as a regression?
Yes, and it has been backed out as a consequence.

Comment 4

[alexander :surkov (:asurkov)]

Marco, can you please give a try to this build https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-5c94ff2cb874135b3bc6f4c83253a2df800c47de/

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #4)
> Marco, can you please give a try to this build
> https://archive.mozilla.org/pub/firefox/try-builds/surkov.alexander@gmail.
> com-5c94ff2cb874135b3bc6f4c83253a2df800c47de/
No, this still doesn't fix the problem. The initial popup menu is never having an accessible created.

In a regular nightly without the patch for bug 1274381, when I open the context menu for a link, a popup menu accessible is being created which has the following properties, got from NVDA's developer information:

Developer info for navigator object:
name: None
role: ROLE_POPUPMENU
states: 
isFocusable: False
hasFocus: False
Python object: <NVDAObjects.IAccessible.mozilla.Mozilla object at 0x050A3470>
Python class mro: (<class 'NVDAObjects.IAccessible.mozilla.Mozilla'>, <class 'NVDAObjects.IAccessible.ia2Web.Ia2Web'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u''
location: (432, 1008, 556, 515)
value: None
appModule: <'firefox' (appName u'firefox', process ID 9060) at address 52387b0>
appModule.productName: u'Nightly'
appModule.productVersion: u'50.0a1'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 2819400L
windowClassName: u'MozillaDropShadowWindowClass'
windowControlID: 0
windowStyle: -1778384896
windowThreadID: 3956
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible2) ptr=0xba139ec at 5248e40>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2819400L, objectID=-4, childID=-13
IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_MENUPOPUP
IAccessible accState: STATE_SYSTEM_FLOATING, STATE_SYSTEM_VALID (4096)
IAccessible accDescription: u''
IAccessible accValue: None
IAccessible2 windowHandle: 2819400
IAccessible2 uniqueID: -13
IAccessible2 role: ROLE_SYSTEM_MENUPOPUP
IAccessible2 states: IA2_STATE_VERTICAL, IA2_STATE_OPAQUE (132096)
IAccessible2 attributes: u'margin-left:0px;text-align:start;text-indent:0px;id:contentAreaContextMenu;tag:menupopup;margin-right:0px;margin-top:0px;margin-bottom:0px;display:-moz-popup;'

In the above try build, this container is never created, along with a bunch of other menus that are usually present when you inspect the first level of accessibles below the main the Firefox window accessible. This container usually contains the children like "Open link in a new tab". In the try build, all these menu items appear, without a container, as children of the main Firefox window accessible. They have no popup menu as container and are thus not recognized as proper menu items.

So the hierarchy at this level right below the Firefox application is broken by bug 1274381.

Comment 6

[alexander :surkov (:asurkov)]

I do definitely see a menupopup accessible and all menuitems contained by it in DOMi. Here's a fresh try build: https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-e3c11b3523f8802be9238cf36cb1c817d5fc0ff0/

Comment 7

[Andrew Overholt [:overholt]]

David, is it possible to verify the status here?

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Andrew Overholt [:overholt] from comment #7)
> David, is it possible to verify the status here?

Marco can confirm when back (mid August) -- this bug isn't valid while bug 1274381 remains backed out. I'm not sure how we want to do flag status for that... perhaps status-firefox50:disabled is closest for now.

Comment 9

[Andrew Overholt [:overholt]]

OK let's mark it unaffected and I'll put a note in bug 1274381 to mark this bug when that one re-lands.

Comment 10

[alexander :surkov (:asurkov)]

finally I tried the patch on Windows + NVDA, context menu is announced. I'll try to reland the patch from bug 1274381.

Comment 11

[Marco Zehe (:MarcoZ)]

I can no longer reproduce the bug in the latest 51.0a1 2016-08-14 Nightly build. Marking this bug as WORKSFORME. Firefox 50 is unaffected I think because bug 1274381 never landed there. Marking accordingly.

Comment 12

[Marco Zehe (:MarcoZ)]

Sorry, have to reopen this one. Seeing the bug again today, in current Nightly build, and this now extends to the main menu bar on Windows as well. The accessibles for File, Edit, View, etc. are not there, and the pull-down menu items like Settings, Add-Ons and others, are direct children of the main application frame accessible, on the same level as the tabs toolbar, main navigation toolbar and outerDoc accessibles that contain individual open tab documents.

Comment 13

[alexander :surkov (:asurkov)]

just finished a fresh build of nightly on windows, tried a context menu on the in-page search field and on the link 'choose from thousands of add-ons', the tree looks ok in DOMi, all menu items are contained by a menupopup accessible. NVDA always says 'menu' when I press shift+f10.

is it something you can reliably reproduce? is the behavior same though previous builds?

Comment 14

[Marco Zehe (:MarcoZ)]

I don't know what caused the context menus to work in the 2016-08-14 build temporarily when I closed the bug on Monday. All I know is that, after the update to 2016-08-15, the bug returned, and also the main menu bar items are gone from the tree. I inspect the IA2 tree, not the tree via DOMi. And NVDA definitely no longer reads the menus and context menus for me, like I initially described for context menus when I filed the bug after bug 1274381 landed.

And all I need to do is start a regular nightly build. When it loads with my last loaded tab, like Gmail, the bug is present immediately, I don't need to do anything else.

Comment 15

[alexander :surkov (:asurkov)]

downloaded 08-16 build [1], tried context menu on links on ftp.mozilla.org, NVDA (2016.2.1) says 'menu' on Windows 10 and I'm able by arrowing it; have shown a main menu by alt, NVDA navigated me by arrows through menus, navigated to Help -> About to double check the build version. I'm not sure what's wrong with my or Marco's system.

do we have other confirmations of any of the observations?

[1] https://ftp.mozilla.org/pub/firefox/nightly/2016/08/2016-08-16-03-04-59-mozilla-central/firefox-51.0a1.en-US.win32.zip

Comment 16

[Marco Zehe (:MarcoZ)]

Alex, your suspicion from yesterday that this might be a timing issue could be the case. Today, my Nightly updated from the 2016-08-16 to the 2016-08-17 build. After the restart, the bug was present. After I shut down and restarted Firefox again, the bug was gone, for both Menu bar and context menus. So after the update process finishes and Nightly restarts, the bug seems to happen more often.

Comment 17

[alexander :surkov (:asurkov)]

bug 1296113 has been landed, I don't expect to help it here, but it will improve a logging. So when it is in Nightly, Marco could you send me a log please having this environment variable set:
export A11YLOG=tree,verbose;

Comment 18

[Marco Zehe (:MarcoZ)]

I've now tried several times to reproduce it. The bug only happens when Nightly is being relaunched after the update to a newer Nightly. Problem is that, as soon as I start Firefox from the shell and it pipes the log to a file, when the update process starts, the logging stops. The process is different, and the new process does no longer pipe the output to the original shell call. :-(

Comment 19

[alexander :surkov (:asurkov)]

it might be same problem as in bug 1280551

Comment 20

[alexander :surkov (:asurkov)]

any luck/unluck to reproduce after bug 1280551 is fixed?

Comment 21

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #20)
> any luck/unluck to reproduce after bug 1280551 is fixed?
This problem is fixed after bug 1280551 landed! \O/