59797 - Should disabled menu-items get highlighted?

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Håkan Waara]

I think this one can be sortof annoying. Should disabled menu-items really be
highlighted when mouse-overed?

This may be a matter of taste, but it seems more clear if enabled menu-items get
highlighted and disabled not. Like in MacOS.


I'm using Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001010

Comment 1

[Boris Zbarsky [:bzbarsky]]

I believe that on windows the platform standard is to highlight disabled menu items.

Comment 2

[Håkan Waara]

Yes, but what's the point of it? Highlightings are normally used to _highlight_
available menus.

Comment 3

[Warner Young]

It may be disconcerting for Windows users to have disabled menu items NOT
highlighted, though.  When I did some owner-draw menus a while back, I forgot to
hilight disabled items, and I found it very odd.  It looked as if the system
wasn't responding correctly when the mouse moves over a disabled item, since I
could see no visible feedback.

Maybe this should be a flag of some sort, so the default behavior suits the
target OS?

Comment 4

[Håkan Waara]

Yes, that would be great. So that MacOS users could have disabled menus not 
highlighted.

Who'll fix this?

Comment 5

[André Dahlqvist]

Disabled menus are highlighted on Linux too. This is the behaviour I expect, and
I would find it confusing if it suddenly jumped over items that were disabled.

Comment 6

[John Morrison]

We already don't highlight disabled menus on Mac, and do highlight disabled
menus on Linux and win32 where it is convention. 

Comment 7

[Håkan Waara]

Ok, then I guess I'll just mark this as a WONTFIX.

Thank you everyone for the help!

Comment 8

[Mike Pinkerton (not reading bugmail)]

um, we do hilight disabled menus on mac. try the context menus.

Comment 9

[Mike Pinkerton (not reading bugmail)]

taking back

Comment 10

[David Krause]

Giving QA to jrgm since this is now assigned to a real person.

Comment 11

[timeless]

This bug is labeled macos, so let's ask the macos people, esp lordpixel since
he's the one improving the context menus.

<offtopic subject="windows, et al">The reason you have selection is to help
indicate position. If you only have one device (mouse) then you really don't
need selection as long as you have a cursor and can assure the user that what
they click is what you will click.  On windows there's this wierd thing called a
keyboard, and due to historical reasons beyond our control, people use it, even
to control menus by "walking" them.  In English, you can open a menu and then
use the arrow keys to navigate to a seleciton of your choice.

File>
 New>
 disabled
 disabled
 disabled
 Save
 disabled
 Quit
 disabled

Suppose that's your file menu and you're walking it with arrow keys and you have
no selection indicator, the result is you might lose track of which entry was
the next entry, press "<down>; <enter>" and select quit when you wanted save.
For some reason, people don't like that outcome.

The other wierd thing about windows, is that it likes to explain what a menu
item or object does, even when it's disabled (eg, ie's edit menu when copy is
disabled, you still get status help for it). If you decided to solve my first
example by skipping over all disabled items then the keyboard bound user would
be unable to get help for those disabled menu items. [yes we don't offer such
help in mozilla yet, but I hope that will be fixed.]</offtopic>

Comment 12

[Andrew Thompson]

Heh. Seems the checkin to make the Mac classic skin track appearance system 
colours "fixed" this issue for Mac contextual menus as I seem to have stopped 
them from being highlighted. Didn't really intend to do that :)

So a couple of points methinks:

* Menus in the main menubar on Mac OS are native. They won't highlight disabled 
items. This is consistent with every other Mac app.

* As of today, contextual menus don't highlight disabled items on Mac OS either. 
This is probably good as its consistent with menus in the menubar.

* Actually, and this came up in the classic skin colours bug 57490, Mac 
contextual menus *never* display disabled items. Arguably there should eb a bug 
which reads "Make disabled items in Mac context menus display:none" 

I'm guessing this is because Apple seem to want to strongly tie contextual menus 
to actions that *can* be performed on the object clicked. For this to work, you 
have ot be convinced that all possible options are visible in one of the menus in 
the menubar.

This is actually what the Mac OS UI guidelines demand - that a contextual menu 
should never contain an option that isn't also available through some other user 
interface mechanism (usually an item in the main menu). I'm not 100% certain this 
is true in Mozilla? Do we have options which are context menu only? If so I think 
we must stick with disabled, non highlighting items rather than hiding 
unavailable options in the contextual menu.

Comment 13

[Matthew T (active 1999-2002)]

No, disabled items should not be highlighted on Mac OS, *except* where we have a 
Mozilla-specific hack to navigate the menu items with the keyboard for 
accessibility purposes (e.g. bug 36665). Then, as in Windows and X, navigating 
through (and therefore highlighting) disabled items (so that items are a 
consistent number of arrow-key presses away from the top/bottom of the menu) is 
more important than the misleading aspect to the feedback.

BTW, we probably should *not* have a bug for having disabled context menu items 
as display:none on Mac. For example, the page context menu should always start 
with `Back' and `Forward'; and if `Forward' was invisible sometimes (rather than 
just disabled) it would absolutely ruin your muscle memory for the rest of the 
items in the menu.

We do have items which are context-menu only, see bug 34357.

Comment 14

[Mike Pinkerton (not reading bugmail)]

no one knows what this bug is anymore, and it appears to have been fixed, sorta
kinda.

please open a new one if you have other concerns. this is a dead horse.

Comment 15

[Håkan Waara]

Actually, this shouldn't gotten marked FIXED. But to avoid spam I will just 
verify it. It's resolved after all.