Closed Bug 66254 Opened 24 years ago Closed 12 years ago

submenus should act like real Mac submenus (selection is too difficult)

Categories

(Core :: XUL, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: mpt, Assigned: mikepinkerton)

References

()

Details

(Whiteboard: [2012 Fall Equinox])

This is son-of-bug 5927, which was fixed by adding a delay to the closing and opening of XP Toolkit submenus to make it easier to go from a main menu item to a submenu item. That's how native Windows submenus work, but native Windows submenus suck bad. They make you wait ages before submenus open, even if you don't want to, they can highlight items for submenus without ever opening them, and they close a submenu too quickly when you're trying to select an item near the bottom of the submenu. Here's how it should work. When the user mouses over an item which has a submenu, highlight the menu item immediately, but wait 250 milliseconds before opening the submenu. This still seems instantaneous, but it saves a lot of flickering and lag as you make your way down the parent menu, and also guards against the edge case that the submenu is so massively wide that it covers the main menu and leaves you unable to get to items below it. (For bonus points, if you need to load stuff in order to show the submenu, start doing that *during* the 250 ms pause, rather than when it ends.) Now, when a submenu is opened, draw yourself a trapezoid with these four points (these are for a submenu which is opened to the right of the main menu -- reverse `left' and `right' below if the submenu is opened on the left): (1) the top left corner of the parent menu item (2) the top left corner of the submenu (this is just in case the submenu is too tall to be completely southeast of the main menu item, in which case it should be partly northeast as well) (3) the bottom left corner of the submenu (4) the bottom left corner of the main menu item. If the cursor goes from the parent menu item (not just from anywhere) into a part of that trapezoid which is outside the parent menu item, start a timer which lasts for 1000 milliseconds. At the end of that 1000 ms, *or* if the user goes outside the trapezoid, close the submenu and do whatever is appropriate for wherever the user is now -- e.g. if the cursor is now over a new submenu parent item, highlight that item, and then open the submenu after 250 ms if the cursor is still there. If the cursor goes anywhere outside the trapezoid, close the submenu immediately, and do whatever is appropriate for where the cursor is now.
Alternatively, do a wrapper which turns XP Toolkit menu structures into native menus ...
While opening submenus may be too fast (or too slow) for some, there IS a system setting for this on Windows. You can only alter it using TweakUI or a similar utility, but it can be changed. It would probably be better to use this setting for the submenu opening delay on Windows, than to set an arbitrary delay which might work for some, but not for others.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
i seem to recall that we do use that setting. maybe not.
Mike, I just checked, and yes, that setting is already used. So if I understand the original bug description, at least part of it (taking too long to open submenus) should be considered resolved.
No, because there is no such setting on Mac OS, for which this bug was filed. Such a setting does not help, anyway; it only allows you to choose between submenus opening too slowly and submenus closing too quickly.
The menu delay has been configurable forever, using the LookAndFeel system. It works great. (I set my delay long, to get Motif/Be style menus.) user_pref("ui.submenuDelay", [msec]); I think the Windows look&feel is supposed to default to the system setting. Are people talking about a different sort of menu delay here? Or is the bug that the Mac default is wrong?
No, because there is no such setting on Mac OS, for which this bug was filed. Such a setting does not help, anyway; it only allows you to choose between submenus opening too slowly and submenus closing too quickly. If you find the original bug description too difficult to understand, please tell me, and I'll draw a diagram. Steps to reproduce #1: * Arrange your bookmarks so that two folders are immediately adjacent to each other, and so that the first of these folders contains lots of items. * Open the Bookmarks menu on the Personal Toolbar, and hover over the left end of the first folder item to open its submenu. * Drag diagonally down towards the bottom item of the submenu. What happens: * The second folder (and other items in the menu) highlight when moused over, even though the second folder submenu does not open when highlighted, and even though the other moused-over items are not at all related to the open submenu. What should happen: * Nothing, until (a) 1000 ms passes, or (c) you go outside the trapezoid (e.g. you get to the submenu) -- whichever happens first. Steps to reproduce #2: * With the same set of bookmarks, hover over the left end of the first folder item to open its submenu. * Move the mouse vertically down to the second folder item. What happens: * You have to wait some delay period for the second submenu to open. This makes it unnecessarily difficult to browse through a large set of submenus (e.g. the Start menu hierarchy in Windows). What should happen: * The second submenu should open immediately.
Seem's you're missing Mathew's point. A time delay is not the optimal solution. See Tog's answer to question 6: http://www.asktog.com/columns/022DesignedToGiveFitts.html
Matthew, sorry. I misunderstood the problem from your original description. Your second explanation clarified it for me. However, (since I don't have a Mac to try this with) when I try it with the Windows Mozilla, I find that there is another way to do this. That is, set the auto submenu open delay to something quite long, and click on each folder item to make it open. On Mozilla, a folder item seems to open immediately when you click (something that NS 4.x seems to do wrong). It seems to me like this would get around the problem to some extent, but then again, the current scheme has never bothered me. I suspect that this is really a personal preference thing, where different folks will prefer different approaches.
2 years later... Actual sytem menu bar items behave properly, but Moz-specific submenus, such as folders in a Personal Toolbar folder, act more like Windows submenus.
Blocks: 32494
OS: Mac System 9.x → MacOS X
Summary: Nested menu selection is too difficult → submenus should act like real Mac submenus (selection is too difficult)
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Is this still actual?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?]
Resolved per whiteboard
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?] → [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.