Open Bug 182448 Opened 18 years ago Updated 2 years ago

Disabled/grayed-out menu items still highlight when alt shortcut key is pressed and fail with no feedback


(Core :: DOM: UI Events & Focus Handling, defect)

Windows 98
Not set





(Reporter: brendan, Unassigned)


User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126

If a menu item is disabled, it shouldn't be able to be highlighted when you
press its shortcut key, most especially when it shares a shortcut key with
another item.

Reproducible: Always

Steps to Reproduce:
1. Open any page with a link.
2. Right-click on the link.
3. Press C to highlight "Copy Link Location".
4. Press C to highlight "Copy" (grayed out/disabled)
Actual Results:  

Expected Results:  
Run "Copy Link location"'s event at step 3.

A work-around for this example would be to assign a different shortcut key to
"Copy Link Location" or assign different (additional) shortcut keys
automatically when two items have the same shortcut key. ie, &Cop&y and &Copy
L&ink Location (I'm not sure how you're supposed to markup the shortcut key in
text form). The best, however, would be to disable the shortcut key for disabled
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Closed: 15 years ago
Resolution: --- → EXPIRED

I don't know what the "standards" or accessibility issues may be, but it seems illogical to me that inactive shortcut keys should be active. 

And if active it doesn't seem right that it should make the menu in use disappear with no feedback to the use of any kind when the attempted invocation of the disabled function fails: no bell, nothing in the status area, etc.  bad user experience.

Perhaps this is standard practice. It behaves this way in ms-word, SSH. Still, no or poor feedback just doesn't seem right. Example in Firefox, with no text selected:
1. alt-E
2. alt-D (delete) 

conversely, when disabled item is clicked via mouse (command and context menu), the menu remains at the same position.
Bug 109841 -  Disabled items in contextual menus shouldn't highlight on mouseover on Mac OS
Bug 67605 -  "rename" and "delete" should be shown on all folder context menus, even if disabled

I couldn't find a realted WONTFIX or other precedent setting bug
Assignee: saari → nobody
Severity: minor → normal
Component: Event Handling → Keyboard: Navigation
QA Contact: rakeshmishra → keyboard.navigation
Resolution: EXPIRED → ---
Summary: Disabled/grayed-out menu items still highlight when shortcut key is pressed. → Disabled/grayed-out menu items still highlight when alt shortcut key is pressed and fail with no feedback
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.