Last Comment Bug 376649 - F10 key should show active menubar item and open submenu
: F10 key should show active menubar item and open submenu
: access, helpwanted, pp, sec508
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All Linux
: -- normal with 1 vote (vote)
: mozilla15
Assigned To: Mounir Lamouri (:mounir)
: Neil Deakin
Depends on: 940040
Blocks: focusnav fox3key
  Show dependency treegraph
Reported: 2007-04-05 13:41 PDT by Aaron Leventhal
Modified: 2013-11-21 03:19 PST (History)
20 users (show)
roc: blocking1.9-
reed: wanted1.9+
mounir: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch v1 (1.68 KB, patch)
2007-04-24 07:48 PDT, O. Atsushi (Torisugari)
no flags Details | Diff | Splinter Review
Makes menu pop down when F10 is hit (Updated old patch for current trunk) (1.39 KB, patch)
2009-08-25 15:05 PDT, Micah Gersten
no flags Details | Diff | Splinter Review
Patch v2 (with ifdef) (1.44 KB, patch)
2009-08-25 15:51 PDT, Micah Gersten
enndeakin: review-
Details | Diff | Splinter Review
Patch v1 (32.93 KB, patch)
2012-05-15 16:12 PDT, Mounir Lamouri (:mounir)
bzbarsky: review+
mounir: checkin+
Details | Diff | Splinter Review
Diff between original and gtk test file (5.45 KB, patch)
2012-05-15 16:16 PDT, Mounir Lamouri (:mounir)
no flags Details | Diff | Splinter Review

Description Aaron Leventhal 2007-04-05 13:41:14 PDT
Under Gnome the F10 key isn't working properly. It's focusing the menu but there is no visual indication of that. You can only tell by pressing down arrow, which flips open the menu.

Not only that, but things should behave slightly differently than under Windows. The F10 key should highlight the first item (e.g. "File"), but visually open the menu. This is different from something like Alt+F which would open the menu and select the first item in that submenu. And, it's different from Windows where F10 just highlights the item on the menubar and doesn't open anything.

My guess is that the highlighting is broken because under Gnome, there is no visual change when you simply mouseover an item in the menubar.
Comment 1 Aaron Leventhal 2007-04-05 13:43:07 PDT
Section 508 because focus is not visibly shown where it is, after F10.
Comment 2 O. Atsushi (Torisugari) 2007-04-24 07:48:43 PDT
Created attachment 262641 [details] [diff] [review]
Patch v1

I don't understand why Windows build works without MenuOpen.
I should look into Windows implementation a bit more. Anyway,
probably this patch is not the way to go.
Comment 3 Tim Keenan 2007-08-31 11:43:40 PDT
Requested blocking because of sec508 compliance.  This would affect both magnification and reading.
Comment 4 Ginn Chen 2007-09-25 20:46:00 PDT
The problem is on Windows, the menu is not expected to open when you press F10 or Alt.
But on GNOME, the menu is opened when you press F10.
So on GNOME, it doesn't have a highlight but not open style, that's why there's no visual change.
It's not a bug of GNOME, because this situation doesn't exist for GNOME apps.

If we want to use this patch, we need to add #ifdef
Comment 5 Kevin Brosnan 2007-12-05 14:19:23 PST
Related/Dupe Firefox Bug 306236.
Comment 6 Steve Lee 2007-12-05 23:43:49 PST
More info for on Linux where F10 appears not to work at all thanks to  The menu bar is activated but w/o any visual feedback as down arrow opens the file menu. Also right arrow moves selection again w/o visual indication, as subsequent down arrow opens another menu.
Comment 7 Micah Gersten 2009-08-24 22:59:52 PDT
Ubuntu Bug:

I'm experiencing this in Firefox 3.5.2 as well as Firefox 3.7 (trunk).  In trunk, when the menu is highlighted, it whites out the menu name.
Comment 8 Micah Gersten 2009-08-25 15:05:24 PDT
Created attachment 396560 [details] [diff] [review]
Makes menu pop down when F10 is hit (Updated old patch for current trunk)
Comment 9 Micah Gersten 2009-08-25 15:51:07 PDT
Created attachment 396575 [details] [diff] [review]
Patch v2 (with ifdef)

Sorry for the bug noise.  This version of the patch has an ifdef that should leave the current functionality on Windows but display the menu on other systems.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2009-08-25 17:22:32 PDT
Comment on attachment 396575 [details] [diff] [review]
Patch v2 (with ifdef)

Neil's a better reviewer here.  That said, do we want the F10 behavior change on Mac?  Do we want to change the mouse behavior (which I think this patch does)?  Do we want OS/2 to not have the same behavior as Windows here?
Comment 11 Neil Deakin 2009-08-31 12:02:23 PDT
Comment on attachment 396575 [details] [diff] [review]
Patch v2 (with ifdef)

I think you want to write the ifdef blocks such that they only change behaviour on Linux.

This patch will cause the test test_menubar.xul to fail. But updating the test should be simple. There's tests there which checks that alt/F10 highlights but doesn't open the menu. Instead, they will need to check if the menu is open on Linux.

Also, do you want this both for when F10 is pressed and when Alt pressed or just the former?
Comment 12 Joanmarie Diggs 2009-08-31 18:35:49 PDT
(In reply to comment #11)

> Also, do you want this both for when F10 is pressed and when Alt pressed or
> just the former?

My vote would be just for the former because that would be consistent with how native (GNOME/Gtk+) apps work.
Comment 13 John A. Bilicki III 2010-07-07 12:13:41 PDT
I'm going to presume that this bug report is responsible for creating the bug where pressing the F10 key opens and gives focus to the file menu in Firefox on Windows.

It's conflicting with a lot of scripts that I've built, I can't remove this weird and VERY undesirable bug through the keyconfig extension, and the ALT key's functionality does not need to be needlessly duplicated.

I'm not sure who the author of Keyconfig is offhand though what should really happen is helping that person add the file menu's keybinding in that extension instead of forcing everyone on all platforms to deal with this new bug. Their site is located at
Comment 14 Josh Matthews [:jdm] (on vacation until Dec 5) 2010-07-07 12:16:42 PDT
This particular bug report is not at fault, as no action has been taken.
Comment 15 Mounir Lamouri (:mounir) 2012-05-15 16:12:24 PDT
Created attachment 624229 [details] [diff] [review]
Patch v1

Patch applies only for GTK widget. Updated tests to take the change into account. Unfortunately, I haven't find a better solution than writing a new file for gtk given that content can't check which widget we are using.
Comment 16 Mounir Lamouri (:mounir) 2012-05-15 16:16:44 PDT
Created attachment 624230 [details] [diff] [review]
Diff between original and gtk test file

This should be *very* helpful for the review ;)
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2012-05-17 20:21:12 PDT
Comment on attachment 624229 [details] [diff] [review]
Patch v1

r=me, but wouldn't the original patch look like your additional test diff if the new file were created with "hg cp"?  If you did _not_ create it that way, I recommend copying your changed version out of the way, hg removing the file, doing the hg cp, then copying in your changed version and committing.
Comment 18 Mounir Lamouri (:mounir) 2012-05-21 16:33:57 PDT
Comment on attachment 624229 [details] [diff] [review]
Patch v1

Pushed in m-i with the fix asked in previous comment.
Comment 19 John A. Bilicki III 2012-05-21 17:36:17 PDT
Mounir, are you planning to implement this as disabled by default or enabled with an easy way in Firefox's options to disable? The ALT key already works flawlessly in the VAST majority of browsers. By introducing this key you're adding to the already burdensome mesh of keyboard shortcuts and on top of that the functionality you're adding is redundant. What would best serve the community is the ability to use the GUI (or UI or UX as some people call it) to remap keys visually.
Comment 20 Mounir Lamouri (:mounir) 2012-05-22 02:02:55 PDT
F10 is already a shortcut in Firefox and is a common shortcut for GTK applications. This patch is only changing the behavior of that shortcut in the GTK version of Firefox to make it more consistent with other GTK applications. I don't think this should be behind a pref and it should not bother users AFAICT.
Comment 21 Mounir Lamouri (:mounir) 2012-05-22 03:27:18 PDT

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