Open
Bug 57563
Opened 24 years ago
Updated 2 months ago
Should still be able to open disabled top-level menus
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
NEW
People
(Reporter: bugzilla, Unassigned)
References
Details
(Whiteboard: [adt3][ue2])
Attachments
(2 files, 1 obsolete file)
627 bytes,
patch
|
Details | Diff | Splinter Review | |
44.67 KB,
image/jpeg
|
Details |
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...
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.
Reporter | ||
Comment 2•24 years ago
|
||
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.
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.
Reporter | ||
Comment 4•24 years ago
|
||
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 8•24 years ago
|
||
<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.
Reporter | ||
Comment 9•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Summary: Should still be able to open disabled menus → Should still be able to open disabled top-level menus
Target Milestone: --- → mozilla1.0
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 14•24 years ago
|
||
Not the Windows standard, and probably harder to implement, but I guess I'm not totally against it.
Comment 15•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 17•24 years ago
|
||
It scares me that I don't think I've ever seen a disabled top level menu on Windows.
Comment 18•24 years ago
|
||
What do the Outlook Express menus look and feel like in the same situation?
Reporter | ||
Comment 19•24 years ago
|
||
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)
Reporter | ||
Comment 20•24 years ago
|
||
*** Bug 62224 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
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.
Reporter | ||
Comment 22•24 years ago
|
||
Yup. Same with the Edit menu, which doesn't even have submenus.
Comment 23•23 years ago
|
||
*** Bug 71918 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
*** Bug 95760 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 26•22 years ago
|
||
*** Bug 139031 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
*** Bug 148322 has been marked as a duplicate of this bug. ***
Comment 28•22 years ago
|
||
*** Bug 29829 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
Give out the graph for discussion.
Comment 30•22 years ago
|
||
*** Bug 129283 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
Nav triage team: nsbeta1+/adt3
Comment 32•22 years ago
|
||
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.
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → mozilla1.4beta
Updated•18 years ago
|
OS: Windows 98 → All
Priority: P3 → --
Hardware: PC → All
Target Milestone: mozilla1.4beta → ---
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•16 years ago
|
Assignee: jag → nobody
Updated•2 years ago
|
Severity: normal → S3
Comment 35•2 years ago
|
||
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.
Flags: needinfo?(enndeakin)
Comment 36•2 years ago
|
||
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.
Flags: needinfo?(enndeakin)
Comment hidden (spam) |
Updated•2 months ago
|
Attachment #9384526 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•