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.
Section 508 because focus is not visibly shown where it is, after F10.
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.
Requested blocking because of sec508 compliance. This would affect both magnification and reading.
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
Related/Dupe Firefox Bug 306236.
More info for on Linux where F10 appears not to work at all thanks to firstname.lastname@example.org. 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.
Ubuntu Bug: https://bugs.launchpad.net/bugs/161961 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.
Created attachment 396560 [details] [diff] [review] Makes menu pop down when F10 is hit (Updated old patch for current trunk)
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 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 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?
(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.
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 http://dorando.at/
This particular bug report is not at fault, as no action has been taken.
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.
Created attachment 624230 [details] [diff] [review] Diff between original and gtk test file This should be *very* helpful for the review ;)
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 on attachment 624229 [details] [diff] [review] Patch v1 Pushed in m-i with the fix asked in previous comment.
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.
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.