Open Bug 367510 Opened 18 years ago Updated 2 years ago

Implement a separate ui.key.menuAccessKey for the right-click menu

Categories

(Firefox :: Settings UI, enhancement)

x86
Linux
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: sy1234, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

If I change ui.key.menuAccessKey to 0 to disable this feature, it disables my right-click menu.

I want to get rid of the hotkey for the menu, because accesskeys and javascript key detection are more important, but when I do this I also disable the "hotkeys" for when I right-click within a page.

I don't see how alt-x for the top-menu is related to right-clicking and pressing a letter.  These two features should be separated into two preferences.

Reproducible: Always

Steps to Reproduce:
1. visit about:config
2. set ui.key.menuAccessKey to 0
3. visit a website, and right-click on the page, a link, an image, etc

Actual Results:  
The menu appears, but nothing is underlined, and pressing letters does nothing.

Expected Results:  
The menu appears, and items are underlined as usual, and pressing a character triggers the appropriate action.
That pref is actually responsible for two different things:
* determining the accelerator key for menus
* disabling all accelerator hints when set to 0 (which is needed for OS X)

What IMO should rather happen though is that for the first of these, ui.key.(chrome|content)Access should be used (depending on context) and the pref for the other should be renamed or abandoned for a native solution (which directly depends on the OS setting).

Note that accesskeys are now activated with Alt+Shift by default so as to not interfere with menus in the first place (and if you've manually changed that, they should override the menus anyway). So in the short-term, you should be able to safely reset ui.key.menuAccessKey to its default value.
I have set ui.key.generalAccessKey to 18 to re-enable my preferred accesskey of "alt".

However, "alt-x" type keystrokes are being used via JavaScript in some situations, so this means that I use these keystrokes and the javascript fires off *and* the menu is activated.

Is there a workaround for me to reassign menu hotkeys to something else?  I'm most interested in reclaiming alt-s.  However, I'm not willing to sacrifice my right-click hotkeys for this.  Perhaps reassigning the current alt-s hotkey for 'history' to something else would work?
(In reply to comment #2)
> However, "alt-x" type keystrokes are being used via JavaScript in some
> situations, so this means that I use these keystrokes and the javascript
> fires off *and* the menu is activated.

Sounds like an error in the script. Returning 'false' from the 'onkeydown' etc
will prevent the menu from handling the event.
Severity: normal → enhancement
I'll follow up with the scripting to get that corrected.

With that in mind, my interest in this bug wanes a fair amount.  I guess it's still useful in some circumstances to be able to deal with the top-menu and the right-click menu differently, but I won't need to once I get this javascript fix.  =)
No luck on the javascript change to fix the problem on that end.  It didn't seem to work.

Well, I decided to get rid of the 'history' menu item, to solve this annoyance.  I've never used that menu item anyways.  =)

http://menueditor.mozdev.org/
This is a mass search for bugs that are in the Firefox General component, are UNCO, and have not been changed for 1000 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the bug, please update this bug. If the issue is gone, please set the resolution to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
Whiteboard: [CLOSEME 2010-11-01]
Component: General → Preferences
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.