Closed
Bug 376649
Opened 17 years ago
Closed 12 years ago
F10 key should show active menubar item and open submenu
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: aaronlev, Assigned: mounir)
References
(Blocks 2 open bugs)
Details
(Keywords: access, helpwanted, platform-parity, Whiteboard: [mozfr])
Attachments
(2 files, 3 obsolete files)
32.93 KB,
patch
|
bzbarsky
:
review+
mounir
:
checkin+
|
Details | Diff | Splinter Review |
5.45 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•17 years ago
|
||
Section 508 because focus is not visibly shown where it is, after F10.
Comment 2•17 years ago
|
||
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.
Updated•17 years ago
|
Flags: blocking1.9?
Comment 3•17 years ago
|
||
Requested blocking because of sec508 compliance. This would affect both magnification and reading.
Updated•17 years ago
|
Keywords: helpwanted
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
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Comment 5•17 years ago
|
||
Related/Dupe Firefox Bug 306236.
More info for on Linux where F10 appears not to work at all thanks to joanmarie.diggs@gmail.com. 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.
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
Comment 7•15 years ago
|
||
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.
Comment 8•15 years ago
|
||
Attachment #396560 -
Flags: review?(bzbarsky)
Updated•15 years ago
|
Attachment #396560 -
Attachment description: Makes menu pop down when F10 is hit → Makes menu pop down when F10 is hit (Updated old patch for current trunk)
Comment 9•15 years ago
|
||
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.
Attachment #396560 -
Attachment is obsolete: true
Attachment #396575 -
Flags: review?(bzbarsky)
Attachment #396560 -
Flags: review?(bzbarsky)
Comment 10•15 years ago
|
||
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?
Attachment #396575 -
Flags: review?(bzbarsky) → review?(enndeakin)
Comment 11•15 years ago
|
||
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?
Attachment #396575 -
Flags: review?(enndeakin) → review-
Comment 12•15 years ago
|
||
(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•14 years ago
|
||
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/
Comment 14•14 years ago
|
||
This particular bug report is not at fault, as no action has been taken.
See Also: → https://launchpad.net/bugs/161961
Assignee | ||
Comment 15•12 years ago
|
||
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.
Assignee: nobody → mounir
Attachment #262641 -
Attachment is obsolete: true
Attachment #396575 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #624229 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 16•12 years ago
|
||
This should be *very* helpful for the review ;)
Comment 17•12 years ago
|
||
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.
Attachment #624229 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Updated•12 years ago
|
Flags: in-testsuite+
Target Milestone: --- → mozilla15
Assignee | ||
Comment 18•12 years ago
|
||
Comment on attachment 624229 [details] [diff] [review] Patch v1 Pushed in m-i with the fix asked in previous comment.
Attachment #624229 -
Flags: checkin+
Comment 19•12 years ago
|
||
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.
Assignee | ||
Comment 20•12 years ago
|
||
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.
Assignee | ||
Comment 21•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b1603afa2ccb
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Whiteboard: [mozfr]
Comment 22•5 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•