57563 - Should still be able to open disabled top-level menus

Status: NEW

(Core :: XUL, defect)

Description

[Blake Ross]

Build ID: new {trunk, branch}

Steps to Reproduce:
(1) Open a Mail Compose window
(2) Make sure the message body textfield doesn't have the focus
(3) Click the disabled "Insert" or "Format" menus -- they don't open. yay!
(3) Click the View menu and hit the right arrow key.  "Insert" doesn't open. 
yay!
(4) Click View to open the menu and then move the mouse over "Insert" 
or "Format".  They open.  Boo...

pink, not sure if this is your problem?  cc'ing dean...

Comment 1

[:deanis74]

I never liked you, Blake.

Just jokin'.

Probably related to bug 32685.  Must have missed checking MenuIsDisabled() for 
menu bar items.

I'm pulling fresh and then I'll take a look at this.

Comment 2

[Blake Ross]

Something about disabling entire menus strikes me as evil, at least on 
Windows.  Matthew?  Seems to me that in most apps, if an entire menu isn't 
useful, it usually isn't shown at all.

Comment 3

[:deanis74]

I'd say no.  I hate dynamically-changing menu bars.  This menu is available some 
of the time in this window - when the message textfield has focus - so it should 
always be visible.  But disabling the top-level item on the menu bar is kind of 
weird.  I think that all menu items under the menu should be disabled, but the 
item on the menu bar should always be enabled.

Comment 4

[Blake Ross]

Yeah, I agree -- it seems important to let the user know that there are more 
options available to them if they click in the message body (which the disabled 
state is somewhat indicative of).  Still seems weird to me on Windows though.

I don't think the solution of disabling all the items in the menu but leaving 
the menu enabled is any better.  It'll probably just cause the user to open the 
menu thinking there's stuff he can do with it, when there really isn't.

Comment 5

[:deanis74]

Either way, there's a bug here that needs to be fixed.

Comment 6

[:deanis74]

Attachment: This fixes it.

Comment 7

[:deanis74]

Adding keywords.

Comment 8

[Matthew T (active 1999-2002)]

<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-76.html> 
(emphasis added):
|
| Menu titles always remain visible. If all the operations in a given menu are
| currently unavailable (that is, the user can't choose them), dim the title by
| drawing it in gray. The user *can still open the menu and see the names of the
| operations* when a menu is dimmed.

<http://msdn.microsoft.com/library/default.asp?URL=/library/books/winguide/
ch08b.htm> (emphasis added):
|
| If all items in a menu are disabled, disable its menu title. If you disable a
| menu item or its title, *the user can still browse to it or choose it*. You
| should include a status bar message, balloon tip, or other context-sensitive
| Help support indicating that the command is unavailable and why.

Even disregarding platform consistency, the behavior described above is just 
plain common sense. It's better that the user can find a menu item in the menus 
and see that it's disabled, than that they waste time hunting around the enabled 
menus wondering if the item exists at all.

So what needs to happen here is the following.
A.  Code needs to be added which gives a menu/submenu title disabled appearance
    whenever all its child items are disabled.
B.  Code needs to be added which disables all menu/submenu items when the
    menu/submenu title is itself disabled (without forgetting their original
    enabled/disabled state for when the menu/submenu is enabled again).
C.  A check of the code should be made to ensure that the fixes for (A) and (B)
    don't chase each other's tails by endlessly disabling each other.
D.  Blake's (3a) and (3b), *not* (4), need to be fixed so that the user can still
    open and browse disabled menus by all the same methods which they use to open
    enabled menus.
E.  As far as I can tell, bug 32685 should be reopened, its fix should be backed
    out, and it should be marked INVALID.

Comment 9

[Blake Ross]

Hmm.  Making the item look disabled but still accessible seems awfully strange 
to me (and I don't recall ever seeing that).  But if it's the spec...

With regards to bug 32685: looking through various Windows apps now, it seems 
that the convention is to leave the parent of the submenu enabled, but to 
disable all the submenu items.  This seems good to me.  But then, why is top 
level menu behavior any different?

Comment 10

[:deanis74]

A. and B. could both be handled in the chrome for now

D. What I read the Windows guidelines to be saying is that you can still select 
the top-level menu item, not that it will open up.  This is different than the 
Mac guidelines.  I did some playing around with standard Windows menus and, 
following the Windows guidelines:
  - #3a should not be fixed completely.  When you click on a disabled top-level
    menu item, it highlights but doesn't open.
  - #3b should work the same as 3a.  Pressing the right arrow key should
    highlight the menu but again not open it.
  - #4 should still be fixed, but not how I fixed it since I don't allow
    disabled top-level items to be selected at all.

E. (bug 32685) I agree with Blake, which is why I filed that bug in the first 
place.  Leave its fix in there.  Didn't realize that top-level menus behaved 
differently, probably because it's so odd to have a top-level menu disabled.

Comment 11

[Matthew T (active 1999-2002)]

Dean, I think your interpretation would be correct if the Windows guidelines just 
said `the user can still browse to it'. But they say `the user can still browse 
to it *or choose it*', which to me means the user can open the menu or submenu.

For something this subtle, if the platform guidelines and common sense agree, but 
disagree with convention, I'd follow the platform guidelines rather than the 
convention.

Comment 12

[:deanis74]

Choosing a menu, to me, means highlighting it.  If they meant that it could be 
opened, they would have said something about opening it or dropping it down.  If 
you interpret things that way, then there is no difference between the spec and 
the actual behavior.

Comment 13

[Mike Pinkerton (not reading bugmail)]

throwing in my $0.02 as unresponsive module owner, I like the mac way, where
disabled top-level menus can be opened and their contents examined.

not a must-have, though, maybe for 1.0

Comment 14

[:deanis74]

Not the Windows standard, and probably harder to implement, but I guess I'm not 
totally against it.

Comment 15

[[e-mail]]

Just to clarify, the Windows behaviour is that disabled menus can be selected
but not opened. If the View menu is open, then right arrow will highlight the
Insert menu. A subsequent left arrow will open the View menu. Out of curiosity,
what is the Mac behaviour for disabled submenus?

Comment 16

[Matthew T (active 1999-2002)]

The Mac behavior for disabled submenus is that they cannot be highlighted or 
opened. On Mac OS, there isn't normally keyboard access to menus, so disabled 
menu items can not be highlighted because this would lessen the effectiveness of 
the highlighting feedback. So I guess consistency of the closest aspects is 
applying here -- it's more important that disabled submenus are consistent with 
other disabled menu items, in being unselectable, than that they are consistent 
with disabled top-level menus in being explorable. Interestingly, MS Excel 98 
hacks keyboard access into its own menus: disabled items are highlightable in 
this mode (to make keyboard navigation easier), and submenus in which all items 
are disabled are still enabled to allow them to be opened and explored using the 
arrow keys.

I still think disabled top-level menus on Windows should be openable, because the 
usefulness of being able to see what's in the menu outweighs the slight 
inconsistency with other Windows apps.

Comment 17

[Blake Ross]

It scares me that I don't think I've ever seen a disabled top level menu on 
Windows.

Comment 18

[Matthew T (active 1999-2002)]

What do the Outlook Express menus look and feel like in the same situation?

Comment 19

[Blake Ross]

All of its menus are enabled regardless of where focus is (message body or the 
fields in the top half) because there are items in the Insert and Format menus 
that you can use regardless (Insert Attachment... for Insert, and things like 
Background, Encoding, and Rich/Plain text for Format)

Comment 20

[Blake Ross]

*** Bug 62224 has been marked as a duplicate of this bug. ***

Comment 21

[:deanis74]

Well, wouldn't you know it?  MS has gone and changed things in Office 2000.  
And, of course, in doing so they've contradicted their own published guidelines.

If a menu is disabled, the item on the menu bar is still enabled, which is no 
different.  But if all items of a submenu are disabled, its parent is still 
enabled.  For example, if you don't have a document open in Word 2000, the 
top-level Insert item is still active.  Drop down that menu and there are two 
items that are active, AutoText and Picture.  Both of these open submenus, and 
when you open the submenus, all items in there are disabled.

Even though this goes against what they've documented ("If all items in a menu 
are disabled, disable its menu title"), it kind of works for me.  It's not 
restrictive, in that it allows the user to explore all menus even if they have 
no available commands.  I vote for adopting this behavior.

Comment 22

[Blake Ross]

Yup.  Same with the Edit menu, which doesn't even have submenus.

Comment 23

[:deanis74]

*** Bug 71918 has been marked as a duplicate of this bug. ***

Comment 24

[[e-mail]]

*** Bug 95760 has been marked as a duplicate of this bug. ***

Comment 25

[Mike Pinkerton (not reading bugmail)]

new owner

Comment 26

[Vadim Berezniker]

*** Bug 139031 has been marked as a duplicate of this bug. ***

Comment 27

[timeless]

*** Bug 148322 has been marked as a duplicate of this bug. ***

Comment 28

[timeless]

*** Bug 29829 has been marked as a duplicate of this bug. ***

Comment 29

[Henry Jia]

Attachment: How Office 2000 handle disabled menu

Give out the graph for discussion.

Comment 30

[Jesse Ruderman]

*** Bug 129283 has been marked as a duplicate of this bug. ***

Comment 31

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 32

[:deanis74]

If that nsbeta1+ is for fixing the original problem as reported, not the tangent
that this bug went off on, see the patch I attached in comment 6.  No idea if it
still applies, but it's simple to fix.

Comment 33

[Samir Gehani]

-> Jag

Comment 34

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 35

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 36

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.