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.
Alex, if you can't take care of this before vacation, I'll have sheriffs back out and reopen suspected bug 1274381.
Do I understand right that bug 1274381 has been confirmed as a regression?
(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.
Marco, can you please give a try to this build https://email@example.com/
(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.
I do definitely see a menupopup accessible and all menuitems contained by it in DOMi. Here's a fresh try build: https://firstname.lastname@example.org/
David, is it possible to verify the status here?
(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.
OK let's mark it unaffected and I'll put a note in bug 1274381 to mark this bug when that one re-lands.
status-firefox50: affected → disabled
finally I tried the patch on Windows + NVDA, context menu is announced. I'll try to reland the patch from bug 1274381.
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox50: affected → unaffected
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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?
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.
downloaded 08-16 build , 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?  https://ftp.mozilla.org/pub/firefox/nightly/2016/08/2016-08-16-03-04-59-mozilla-central/firefox-51.0a1.en-US.win32.zip
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.
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;
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. :-(
it might be same problem as in bug 1280551
any luck/unluck to reproduce after bug 1280551 is fixed?
(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/
Status: NEW → RESOLVED
Last Resolved: 2 years ago → 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.