Open Bug 1259818 Opened 9 years ago Updated 3 months ago

No keyboard shortcut for Firefox Menu (AKA as hamburger menu)

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Version:
45 Branch
Type:
defect

Tracking

()

People

(Reporter: jeroenpraat, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160304114936 Steps to reproduce: Opening the Firefox Menu (AKA the hamburger menu) on the right side of the browser window with a keyboard shortcut. Actual results: I couldn't find a keyboard shortcut for this button. Expected results: Please add a keyboard shortcut for this important button. It would also be handy to use the arrow keys to select a tile when the menu is opened.
Component: Untriaged → Keyboard Navigation
Sorry, again I didn't saw this other bug.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Please don't call this the hamburger menu, it is obviously the "Cheeseburger in Paradise Menu!"
I'm not sure this is a dupe. That was for the Firefox button. This is for the hamburger menu. And, while it's been a while, I thought Australis was supposed to include a keyboard shortcut for that menu. The logic in that old bug doesn't work now, since there are plenty of functions in the hamburger menu that are not on the menu bar. Addons no longer add options to the menu bar. It actually seems like there is a huge accessibility problem, without any way to access addon features unless the addon happens to include a keyboard shortcut of its own.
I agree this is not a dupe and the other bug should just be closed because the button it referred to no longer exists. Pleas do no re-dupe this without a very good explanation.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
OK, my bad. Thanks for reopening this.
See Also: → 575279
It appears fixing this will not be as quick as I had expected, since similar functionality is handled in c++ classes and so it requires becoming familiar with a lot more of the core code than I thought. But, I set up a local copy of Firefox to work on this, so I think I'll keep reading the code to get enough background. In any case, it's not clear exactly what should happen from a user perspective. What about this as a solution for Windows? (Once agreed for Windows, I'll check out other platforms and suggest the parallel solutions.) If you press Alt, not only does the menubar appear at the top of the browser as it does now, but also the toolbar (where the hamburger menu and the Web extensions are) gets overlay icons: running right to left these could be M, 1, 2, 3, 4, 5, 6, 7, 8. Alt + M opens the menu. Alt + 1 opens the first Web extension (or other button) to the left of the Menu, and so on. Alt+9, copying how tabs work, opens the Web extension on the far left. Once the menubar (where the hamburger menu and the Web extensions are) is in focus, left / right arrows work in the menubar just as they do in the toolbar (where the file menu is at the top of the browser) to move between buttons.
Flags: needinfo?(mzehe)
Yes, there is a much bigger problem here, since those menu panels are not accessible, never have been. That's why, on Windows when you press the Alt key, the "old" Windows XP-style menu bar is still there and carried forward. I know Gijs was working on this years and years back, but it was dropped due to the markup being too non-standard to easily make accessible. I don't know if this has changed, I must admit I've largely ignored this thing for years, since it was never relevant to visually impaired users, for example, since they had the old menu to work with. If this is going to change, adding a keyboard shortcut alone is not enough to make this accessible. I don't know what magic it does, but right now it is largely oblivious to accessibility, firing no focus events, keyboard shortcuts not reacting once the menu is open (like left or right arrows etc.), etc., etc.
Flags: needinfo?(mzehe) → needinfo?(gijskruitbosch+bugs)
We added a shortcut in bug 881937. All the code was backed out in bug 946395. You can read about the reasons and challenges in those bugs. Basically, the point is we have no control over what is in that menu. It's nice to say that arrows should switch between buttons - what about the search bar (how would you arrow through the bar itself?), or other more complex UI added by add-ons? It's just a complex subject, and it would be very hard to get to a point where the a11y story was both coherent, consistent AND predictable/intuitive/discoverable. It should be tackled if/when we get rid of the main menu bar. I don't think anybody is planning to do that any time soon, and so I don't think this is a priority right now.
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 881937
The reason it interests me is that I created an accessibility Web extension, and there's no way to get it to with the keyboard. It uses very standard extension code for Web extensions, which the documentation says will be the standard going forward for Firefox extensions: a browser action, with a default_popup. Would it make more sense, then, to add a Web extensions submenu to the Tools menu in the main menu bar? I could use a different type of extension to fix this for just my extension, but would something that fixes it for all Web extensions with popups be preferred?
actually, that should be all Web extensions with browser actions, whether or not there's a popup
(In reply to Suzanne Taylor from comment #9) > The reason it interests me is that I created an accessibility Web extension, > and there's no way to get it to with the keyboard. It uses very standard > extension code for Web extensions, which the documentation says will be the > standard going forward for Firefox extensions: a browser action, with a > default_popup. Would it make more sense, then, to add a Web extensions > submenu to the Tools menu in the main menu bar? I could use a different type > of extension to fix this for just my extension, but would something that > fixes it for all Web extensions with popups be preferred? I don't know, this is a question for the web extensions folks. The keyboard accessibility of the web extensions browser actions shouldn't depend on the main menu's accessibility though, at least not for the default placement in the toolbar... Anyway, the webextensions side of this probably warrants another bug, but I'll ping folks just to get their attention anyway. Kris, have the webextensions team thought about this? Seems like in Chrome, it's possible to use 'tab' to navigate the toolbar and (I assume, haven't checked) activate extension-provided panels / browser actions.
Flags: needinfo?(kmaglione+bmo)
The browser action keyboard shortcut issue is bug 1246034. That only applies to extensions which explicitly provide a keyboard shortcut, though.
Flags: needinfo?(kmaglione+bmo)
(In reply to Kris Maglione [:kmag] from comment #12) > The browser action keyboard shortcut issue is bug 1246034. That only applies > to extensions which explicitly provide a keyboard shortcut, though. Right... do we have plans to make any of the others accessible? If not, who could drive those plans from within the webextensions group? It shouldn't be the case that only mouse users can use these items.
Flags: needinfo?(kmaglione+bmo)
No plans at the moment, no. I suppose we could add entries for them to the tools menu, but it seems like it might make more sense to just make all toolbar/menu buttons keyboard accessible.
Flags: needinfo?(kmaglione+bmo)
See Also: → 1138131
1325692 - [commands] Explicit support for overriding built-in keyboard shortcuts by WebExtensions <https://bugzilla.mozilla.org/show_bug.cgi?id=1325692>
Blocks: 1418973
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #14) > No plans at the moment, no. I suppose we could add entries for them to the > tools menu, but it seems like it might make more sense to just make all > toolbar/menu buttons keyboard accessible. Depends. I know you can't please everyone but my mouse pointer often rests around where the middle of the hamburger menu opens up to. So instead of memorizing shortcuts for all the things I use I'd rather hit a keyboard shortcut to open the menu and continue from there. But I recognize that it's a fringe case.
Severity: normal → S3

Clarify summary. For keyboard-dependent users, the entire Firefox App Menu is not keyboard accessible because the button isn't.

Summary: No keyboard shortcut for Firefox Menu (AKA as hamburger menu) → Firefox App Menu button (aka hamburger menu) is not keyboard accessible, no shortcut
See Also: → 1795360

(In reply to Thomas D. (:thomas8) from comment #18)

Clarify summary. For keyboard-dependent users, the entire Firefox App Menu is not keyboard accessible because the button isn't.

This isn't really true? You can reach the button with the keyboard and can then access the popup with the keyboard. For example, ctrl-L (or cmd-L on macOS) reaches the url bar, after which you can [tab] to get to the button group at the end of the toolbar, and then arrow key to the hamburger button. Space/enter (depending on the OS) activates the button.

I'm reverting the summary.

Summary: Firefox App Menu button (aka hamburger menu) is not keyboard accessible, no shortcut → No keyboard shortcut for Firefox Menu (AKA as hamburger menu)

While technically true, I'd say that it's not intuitive that an app button would be accessed that way. Perhaps a compromise to say that the menu is not easily (or quickly) keyboard accessible?

(In reply to :Gijs (he/him) from comment #19)

… the url bar, after which you can [tab] to get to the button group at the end of the toolbar, and then arrow key to the hamburger button. Space/enter (depending on the OS) activates the button. …

True, however I would never have imagined so convoluted an arrangement for the main menu of an application.

… the url bar, after which you can [tab] to get to the button group at the end of the toolbar, …

For clarity, the number of keystrokes (with Firefox on FreeBSD):

  1. Control-L to the location field
  2. Tab to the first button of the group within the location field
  3. Tab beyond the location field, to the first button of the next group
  4. Right
  5. Space

– at least five steps, instead of one shortcut.

I'm relatively lucky, in that only eight steps are required, because I keep as few buttons as possible in the second group.

Other users might prefer visibility of buttons. A person with a dozen extensions might require fifteen steps to reach the main menu …

(In reply to Graham Perrin from comment #21)

… only eight steps are required, because I keep as few buttons as possible in the second group. …

Correction, sorry: what was pictured (linked) above was the result of keying Space for the overflow menu. I prefer the main menu to the left, far left; it's nine steps in my case.

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)

I consider this still relevant. I'd also add that it's parity Chrome, as Chrome will automatically select its menu if you press ALT or F10. You then press down to open the menu, or can move it over to other buttons.

When adding shortcut, please keep compatibility with classic menu for users. Keys F10 and Alt are still being used for access to the original / classic / old menu (File, Edit, View, History, Bookmarks, Tools, Help; as a line at left top corner),
so it is neccessary to test new feature when old menu is switched on.

I suggest to make possibility to move cursor between that two menus e.g. by left/right arrow key.

ALT+A might be a good option to open the Application Menu. It doesn't collide with any default shortcuts or legacy menus in Firefox or Thunderbird (at least in Windows 11 and Linux Mint 21.2). It's also similar to legacy menu access keys (ALT+_ scheme, easy to type one-handed, on left side of keyboard).

It seems relevant as some commands ("open password manager", "translate page") aren't in Firefox's legacy menus (circa at least v121.0.1), and don't have their own keyboard shortcuts.

As for Chrome parity, ALT+F opens Chrome's Application menu with the behaviors of a legacy menu (cursor up/dn to select items, can use menu accelerator keys, press ALT again to close menu, etc). Excellent implementation, just needs a different shortcut key for Firefox.

(In reply to Jon Keim from comment #27)

ALT+A might be a good option to open the Application Menu. It doesn't collide with any default shortcuts or legacy menus in Firefox or Thunderbird (at least in Windows 11 and Linux Mint 21.2).

At some point on Linux if you had Emacs-style keybindings enabled, Alt+A was select all (with Ctrl+A being beginning of line). I don't know if that's still supported?

It's also similar to legacy menu access keys (ALT+_ scheme, easy to type one-handed, on left side of keyboard).

But it's very hard to discover. Legacy menus have underlined characters to indicate what to type; I would never guess to try Alt+A.

Whereas I did try F10 for the menu, as a standard keystroke for getting to menus.

To my surprise, that made Firefox open some legacy menus that I didn't even know it had! It seems odd to have the ‘open menu’ keystroke open a secret invisible menu, and not the main menu that's right in front of users.

Also, there are other ways of opening the legacy menu: Alt+F (or any other letter for a menu name in your language) currently does exactly the same as F10. As does Ctrl+F10 for that matter. And Alt on its own makes the legacy menu bar appear, where you can press access keys or use the cursor keys to open a menu.

So if F10 was repurposed to open the main menu that users can see, there would still be convenient (and mnemonic) ways of opening the legacy menus, for users that are aware they still exist.

For what it’s worth, stock GNOME applications do repurpose F10 to open the hamburger menu. (Tested on gedit, gnome-characters, and gnome-system-monitor.)

(Although my personal take is that (1) every command that is in the application menu must be also present in the legacy menu, (2) legacy menu should be referred to as classic menu, and (3) it should be possible to hide the application menu.)

I note that F10 does highlight the app menu on Chrome, as does just pressing the Alt key by itself (not as a modifier). The left and right arrow keys then allow you to move through all of the toolbar buttons, while pressing up or down actually opens the menu, similar to how it works on the classic menu. (Chrome doesn't have a classic menu.)

Note that, in Firefox, the classic menu is still called the Menu bar, and can be made always visible by right clicking on the tab bar and choosing "Menu Bar." It's also available in the Customize menu.

You know, I always forget about F10. (It's just not my habit; I've always used ALT+_. Obviously then, I wouldn't personally mind the change. xD ) And it might be better for accessibility: if you're using Sticky Keys, a single keystroke may be less cumbersome than "ALT, A".

Also, I agree that keyboard shortcuts for buttons are harder to discover than classic menus. Whatever the shortcut, could a hint be added to the tooltip? That's helped me in other modern, button-heavy, low-text UIs.

Interesting that Chrome and GNOME have slightly different interactions. Just to summarize:

GNOME:

  • F10 - opens app menu; up/down keys to select (no accelerators?), F10/ESC to close

Chrome:

  • ALT+F - opens app menu, has "opened classic menu" behaviors (arrow keys, accelerators, ALT/F10/ESC to close)
  • F10 - focuses app menu button but does not open, akin to F10 with a classic menu. Left/right arrow keys move focus to other toolbar buttons. Space/Enter/Up/Down opens the menu.
  • ALT - same as F10

Chrome's pattern for F10 would also provide a quick way to focus the right side of the rightmost toolbar button group (where major functionality resides by default, including the overflow menu and plugin buttons), while not breaking UI consistency work in bug 1418973.

Firefox couldn't easily use Chrome's ALT+F or ALT behaviors, but that's a small loss. (To really sow some chaos, ALT+F10 could perform Chrome's ALT+F? I kid. xD ) Changing F10 could be mitigated by... making "F10, right arrow" focus the File Menu? Though that slightly breaks the overall UI consistency. (To me, from a design standpoint, the App Menu is "just a weird menu" and arrowing between menus, closed or open, always makes sense, but that's just me.)

("Classic" menus! Apologies, not sure where my brain got "legacy" from; every time I typed that I had to pause and think "please don't take my menus away". xD Also agree that all commands in the application menu should also be in classic menus; this just wasn't a bug for that.)

(Apologies if this is a lot of text, especially from someone new. I noticed an interesting UI quirk and suddenly a bunch of thinking happened.)

Alt + A is Menu "Úpr&avy" (Edit?) in old menu, in Czech language,
so new shortcut for new menu would have to be localised for each language to do not collide with old menu.

I think new menu could be kind of zero / last item of old menu, when browsing by left/right arrow:

Alt or F10 to open old menu, when "File" is focused

arrows left/right:
File - Edit - View - History - Bookmarks - Tools - Help - Hamburger - File - Edit - ...

This can be solution.

It would be even fast:
F10 (File), arrow left (hamburger)

“File, arrow left” is supposed to open the system menu on Windows. The one that is bound to Alt+Space and contains top-level window management commands such as Move, Resize, Minimize, Maximize, Close.

And that reminds me of ancient history. Before Windows 95 put the window icon as the system menu indicator, that role was fulfilled by a gray square depicting a long horizontal bar. That was the mnemonic for the space bar. There was also the UI concept called MDI that allowed a top-level window to contain multiple document windows. A document window also had a title bar and a system menu in it; the icon for the document window system menu was a gray square with a short bar. That menu opened on Alt+-.

Case in point: does the Firefox hamburger menu maybe want Alt+- or Alt+= as its somewhat mnemonic hot key? (Additional consideration in favor of Alt+=: Firefox (known as Phoenix way back then) popularized tabs as a replacement for the MDI paradigm, so maybe Alt+- should pop up the current tab’s context menu.)

You need to log in before you can comment on or make changes to this bug.