Affected versions

• Firefox 89.0a1 (BuildId:20210414093129)

Affected platforms

• macOS 10.15.7

Unaffected platforms

• Windows 10 64bit.
• Ubuntu 20.04

Preconditions

• Have the widget.macos.native-context-menus and the browser.proton.enabled prefs enabled.
• Enable VoiceOver.

Steps to reproduce

1. Launch Firefox.
2. Access the following link
3. Right click on the password field.
4. Navigate through the available context menu options.

Expected result

• VoiceOver reads all the available context menu options.

Actual result

• VoiceOver doesn’t read the available context menu options.

Regression Range

• This is not a regression with native context menu turned on.

Notes

• The following errors are being thrown inside the browser console: QM_TRY failure (WARNING): 'Unavailable' at dom/cache/FileUtils.cpp:94 failed with result 0x80520008 (NS_ERROR_FILE_ALREADY_EXISTS)
  And
  Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified.

Note: VoiceOver seems to read those errors even though the browser console is open but not in focus.

(In reply to Emil Ghitta, QA [:emilghitta] from comment #0)

• This is not a regression with native context menu turned on.

By this, do you mean that this bug also exists for non-native menus? Or that it only exists for native menus and that there was no point at which native menus didn't have the bug?

Sorry for the confusion. This bug seems to be reproducible only for/with native context menus. On non-native menus this works as intended.

I see, thanks!

I was able to reproduce this once, on a fresh profile. After that I couldn't reproduce it again. Does this happen consistently for you?

For me, when I right click into the password field it is announced with "menu (12 items)". On some tries, the announcement is aborted quickly and replaced with the announcement "Password, secure edit text".

Investigated this a bit more:

The "error reading" problem seems to actually occur while the browser console was open but not in focus. The "error reading" part is encountered in non-native menus as well. Sorry for the false alarm on this.

So, I Think that the problem can be resumed to the fact that the native context menu options for password field are not being read by VoiceOver.

Updating comment 0.

(In reply to Emil Ghitta, QA [:emilghitta] from comment #0)

4. Navigate through the available context menu options.

Just to be extra certain we're all on the same page, how did you "navigate" in this instance? Did you use the cursor keys, VO+right, the mouse, ...? Thanks.

Oh, I was using the cursor keys to navigate through the context menu options.

Using VO+down arrow seems to work (VoicOver reads through the available context menu options).

Ok. Now I'm constantly hitting the "error reading" problem with native context menus enabled. It seems that I can reproduce this constantly after performing a browser restart via browser console (after manually switching the widget.macos.native-context-menus pref to true) and then accessing twitter's login page. VoiceOver keeps reading those errors constantly (sometimes I need to close VoiceOver or Firefox to make it stop).

I managed to capture this behavior on a screencast (Mozilla account needed).

Emil, in your VoiceOver utility, do you have cursor synchronization enabled?

Yes, I have the "Synchronize keyboard focus and VoiceOver cursor" option enabled.

Huh okay a few observations here:

• I can't reproduce the non-navigable menu, even with a fresh profile or restarting via the browser console :( The menu consistently launches for me and I can consistently navigate the items with both VO commands and the arrow keys. This is true if I launch the menu with my mouse or with VO+shift+M, and this is true regardless of if I have native menus enabled or disabled.

• When I try to launch a menu on either of the inputs on the twitter login page, I find I'm only able to get the correct menu when I right click with the mouse. So, I expect to see the context menu that includes the option "Use saved login", but when I use the VO command to bring up that menu, I instead get the page's context menu (the one with back, refresh, etc.). Interestingly, this isn't a problem if I go down to the links at the bottom of the login page -- those give me the link context menu regardless of if I launch with VO or the mouse.

• All that said, I think this odd behaviour is twitter specific. Both their username and password fields have an input box with a visible label inside. I'm not sure exactly how we route the context menu anchor point, but if its (0,0) or the center its likely it is actually launching the menu on the label instead of the input box even though it has the input focused. I also have this problem when I test with safari: sometimes it'll launch the field menu (the one that has 'copy, delete, paste, etc.' options) but the majority of the time it launches the page menu. I think the defining difference is whether or not you've started to enter text in the field. Visually, when that happens, the VO cursor shrink wraps a smaller input inside the larger twitter-styled input. I also see this problem regardless of whether I have native menus enabled or disabled in firefox.

• A problem that I /do/ get, though, is that on other pages, occasionally we're launching the context menu in the incorrect location and/or throwing the mouse when the menu is opened. This is true both for native menus and non-native menus. If I go to the google sign in page (or click 'add another account' from my already-logged-in account), focus the input control for 'username or email' with VO, and then do VO+shift+M, I get the page menu instead of the field menu consistently. This menu also launches in the middle of the page (not tied to the input) and throws my mouse to the left. Safari handles this fine. If I try to launch the context menu on a field here, I get the correct menu, but again the wrong location. Maybe there's something odd about how certain sites do input controls that causes VO or our childAtPoint finder to be wrong?

• As to the errors that you're seeing VO read when you have the browser toolbox open, I'm not sure exactly why that's happening, but VO does auto-read pages if you don't move the cursor with VO commands. It might be that, since you're interacting with the mouse to navigate to the page and open the menu, the auto-read is continuing onto the other window (which has initial focus when you launch your new tab). Could also be we have some issues with the z-index of our hit testing -- maybe VO is tracking to the background window.

NI'ing eeejay for his thoughts on this and to see if he can reproduce

All of this to say: I think there are issues here, but I think they're site-specific, and I don't think they're related to enabling/disabling native context menus

The context menu is navigable for me as well, the problem is that VoiceOver doesn't read the context menu options while navigating through them.

A few notes about this:

• VoiceOver successfully reads the context menu options while navigating using VO+down or/and up arrow key after opening the password filed context menu via mouse or trackpad.
• VoiceOver successfully reads the context menu options while navigating using only the arrow keys after opening the password field context menu via VO+shify+ m.
• Voice over doesn't read the context menu options while using only the arrow keys after opening the password field context menu via mouse or trackpad.

Unfortunately, I can reproduce this behavior using facebook, google or Netflix login pages as well.

In my case, I can reproduce this issue only after enabling widget.macos.native-context-menus.

Ah sorry, by "navigate" I meant VO reads them. When you use the trackpad or mouse to launch the context menu, are you first focusing it with VO? Where is the VO cursor when you click?

Oh interesting! I can reproduce on netflix 🤕 When I launch the context menu, VO throws my mouse to the left and then using the regular arrow keys (no VO modifier) I can traverse the menu but VO doesn't read/the VO cursor doesn't track. Also, not sure where the VO cursor goes after the mouse is thrown, I can't see it visually. When I close the menu with esc, the VO cursor goes back to the password input. I wonder if we're using weird coordinates here.

On my machine, this repros with native menus on and doesn't with native menus off. I'd still like to get another person on the team to test, since this bug seems finicky. Reaching out to asa today, if not, eitan said he can look tomorrow.

Another odd thing: if I launch the menu with the mouse, sometimes it closes before I can even try to use the arrow keys. On further insepction, it looks like the menu opens on mousedown, and if mouseup isn't very-very soon after, the menu will close on mouse up. Maybe this is similar to bug 1696320? I don't have this problem with non-native menus -- they stay open through a subsequent mouse-up even if its seconds later. I have to mouse-down or esc to get the non-native menu to close.

This happens irrespective of VO, so its a problem for all users. I'll flag this on the a11y review bug

It's possible that the macOS version makes a difference here. According to comment 0, Emil found the bug on macOS 10.15. I've found it hard to reproduce on macOS 11, but it's possible that it's much easier to reproduce on 10.15.

(In reply to Morgan Reschenberg [:morgan] from comment #12)

Ah sorry, by "navigate" I meant VO reads them. When you use the trackpad or mouse to launch the context menu, are you first focusing it with VO? Where is the VO cursor when you click?

I tried both scenarios (focusing with mouse/trackpad first and focusing it with VO first).

I've created a screencast. (Here I have the mouse pointer set to follow the VoiceOver cursor).

(In reply to Markus Stange [:mstange] from comment #14)

It's possible that the macOS version makes a difference here. According to comment 0, Emil found the bug on macOS 10.15. I've found it hard to reproduce on macOS 11, but it's possible that it's much easier to reproduce on 10.15.

It seems that I can reproduce this issue using macOS 10.14.5, 10.15 & 11.3

Morgan and I just investigated together there are two issues, both of which are VoiceOver/MacOS bugs that can be reproduced in Chrome and Safari too:

1. As the original STR of this bug suggests, when arrowing through an input context menu when the input has focus VoiceOver does not read the items.
2. When pressing VO+Shift+m to open an input context menu (when both VO cursor and KB focus is on the entry), VoiceOver opens a menu on a different unrelated item.

As I said above, both issues are identical in Safari and Chrome. This is effectively a regression in Firefox since these issues don't exist in our non-native menu implementation.

To give a simplified STR, I can reproduce with the following on 11.2:

1. Ensure "VO cursor follows keyboard focus" checkbox is checked in VO Utility
2. Enable VoiceOver
3. Navigate to data:text/html,<input type="password">
4. Focus the input with the VO cursor by entering the page content (VO+shift+down)
5. Launch the context menu by right clicking the input with the mouse
6. Navigate the menu options using the up and down arrow keys (without the VO modifier)

Expected:
The context menu options are read aloud by VoiceOver and the VO cursor matches focus with the arrow keys as they traverse the menu.

Actual:
The context menu options are not read aloud by VO. The VO cursor does not follow the arrow key traversal of the menu.

Note: this bug is also reproducible on Safari and Chrome, indicating it is likely a VoiceOver bug and/or that no workaround has been found

Thanks for all the testing, Morgan and Eitan!

I'm not getting my hopes up that we can do much here, given that this problem appears in other browsers too. I'm quite surprised that it turns out that our non-native menus have more robust VoiceOver support than the native ones! When I initially wrote the "extra powers" section in bug 34572 comment 22, I never would have guessed that better accessibility would be one of those extra powers.

I'm planning to do some more debugging on this once I'm done with the other context menu regressions.

Hey rtestard, given comment 17 and comment 18 (particularly the fact that this is a bug in other browsers, notably Safari), can we down-prioritize this bug?

WebKit bug counterpart here: https://bugs.webkit.org/show_bug.cgi?id=225069
Looks like it may be an engine bug after all (one that's reproduced across browsers)

FWIW, I can reproduce the same bug in the Mac AppStore if the password field has keyboard focus before triggering the context menu.

We clearly aren't actively working on this. This feels like a subset of bug 1706966, maybe they should be duped? Edit: Okay that one is specific to older macOS.

As we confirmed the bug is in macOS itself and affects all other browsers (or apps) using native menus, I think it's fair to lower the severity.