F10-key don't switch focus to menubar in Mozilla Firefox

Bug #161961 reported by Fred on 2007-11-11
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Low
Unassigned
firefox-3.0 (Ubuntu)
Low
Unassigned
firefox-3.5 (Ubuntu)
Low
Unassigned

Bug Description

I am using Mozilla Firefox on Ubuntu 7.10 Gutsy Gibbon.

When I press the F10-key, it does not open the menu or switch focus to the menubar.

Firefox does this on Windows.
Other applications in Linux also work this way, such as Text Editor and F-Spot, etc.

NOTE:
When you hit F10, it does indeed move the focus, but you have to hit the down arrow to actually notice.

Section 508 because focus is not visibly shown where it is, after F10.

Created an attachment (id=262641)
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

Fred (eldmannen+launchpad) wrote :

I am using Mozilla Firefox on Ubuntu 7.10 Gutsy Gibbon.

When I press the F10-key, it does not open the menu or switch focus to the menubar.

Firefox does this on Windows.
Other applications in Linux also work this way, such as Text Editor and F-Spot, etc.

Related/Dupe Firefox Bug 306236.

More info for on Linux where F10 appears not to work at all thanks to <email address hidden>. 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.

Changed in firefox:
status: Confirmed → New
Changed in firefox:
status: New → Confirmed
Fred (eldmannen+launchpad) wrote :

This still is not fixed in Ubuntu 8.04 "Hardy Heron" (alpha) with Mozilla Firefox 3.0 beta 3. :(

Fred (eldmannen+launchpad) wrote :

This is still not fixed in Mozilla Firefox 3.0 beta 4. :(

Gert Kulyk (gkulyk) wrote :

Citing from http://www.shortcutworld.com/shortcuts.html?id=firefox

---
Accessing and working with the Firefox Menu Bar:

alt or f10: Jumps to the menu bar. From here you can use arrow left, arrow right, arrow up and arrow down plus enter to navigate and activate between the menu items on top of the browser window.

This works at least in gutsy, but as stated: f10 only activates the menu-bar, to open a given menu you'll need to use the arrow-keys. Don't forget that firefox is not a native gtk/gnome application, so there will be always a few differences.

Fred (eldmannen+launchpad) wrote :

Oh, it actually (kinda) works.

You cant use left and right immediatly after you press F10 though. First you must press down or up, then when the menu opens, you can press left or right.

In GTK applications such as gedit, when you press F10 it opens the menu.
In Firefox it is not consistent, because it just moves the focus the menu, kinda like activates it, it doesn't open the menu.

And there is no visual indication in neither Firefox or GTK that it is activated. :(

There should be a hover-effect like in Windows, as a visual indication.

I can confirm what Gert said. In Gutsy I am able to press F10 then navigate the menu bar with my arrow keys. It does not automatically highlight the menu bar with the pressing of F10, you must first use the arrow keys (and possibly press them more than once to have an effect).

Someone with FF 3.0 in Hardy said they were only able to navigate the "File" menu (ie: arrow-left and arrow-right weren't working).

Can anyone confirm this behavior on Hardy?

If it does work in Hardy as it does in Gutsy, this will be marked invalid as the requested behavior is present.

Changed in firefox:
status: Confirmed → Incomplete

Closing bug as this has been confirmed from multiple sources that this behavior is present in Firefox, albeit differently than the implementation in windows or fully GTK applications.

Thanks.

Changed in firefox:
status: Incomplete → Invalid
Fred (eldmannen+launchpad) wrote :

Well, it should work same as in GTK applications...

Consistency...

The current behaviour is confusing...

Alexander Sack (asac) wrote :

we should find the proper upstream bug for this.

Changed in firefox:
status: New → Incomplete

The upstream bug can be found at: https://bugzilla.mozilla.org/show_bug.cgi?id=376649

Please watch that bug for updates add any further information there.

Thanks!

Changed in firefox:
importance: Undecided → Unknown
status: Incomplete → Unknown
importance: Wishlist → Low
status: Invalid → Triaged
Changed in firefox:
status: Unknown → Confirmed
Micah Gersten (micahg) wrote :

Moving to FF3 as no more work will happen in FF2.

affects: firefox (Ubuntu) → firefox-3.0 (Ubuntu)

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.

Micah Gersten (micahg) wrote :

Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Won't Fix
Micah Gersten (micahg) wrote :

Moving tracking to Firefox 3.5

Trying to get this recategorized upstream.

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Micah Gersten (micahg) on 2009-08-25
description: updated

Created an attachment (id=396560)
Makes menu pop down when F10 is hit

Created an attachment (id=396575)
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.

(From update of attachment 396575)
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?

(From update of attachment 396575)
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.

Fred (eldmannen+launchpad) wrote :

This is still an issue in Ubuntu 10.04 LTS with Firefox 3.6.3.

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.

Changed in firefox:
importance: Unknown → Medium
Fred (eldmannen+launchpad) wrote :

4 years later, this bug is still not fixed in Firefox 7.0.1.

Created attachment 624229
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
Diff between original and gtk test file

This should be *very* helpful for the review ;)

Changed in firefox:
status: Confirmed → In Progress

Comment on attachment 624229
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.

Micah Gersten (micahg) on 2012-05-18
Changed in firefox-3.5 (Ubuntu):
status: Triaged → Won't Fix
Changed in firefox (Ubuntu):
importance: Undecided → Low
status: New → Triaged

Comment on attachment 624229
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.

Changed in firefox:
status: In Progress → Fix Released
Paul White (paulw2u) wrote :

Upstream bug report closed "RESOLVED FIXED"
Confirmed fixed in Ubuntu 18.04 / Firefox 61

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.