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

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[Matthew T (active 1999-2002)]

Alternatively, do a wrapper which turns XP Toolkit menu structures into native 
menus ...

Comment 2

[Warner Young]

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.

Comment 3

[Mike Pinkerton (not reading bugmail)]

i seem to recall that we do use that setting. maybe not.

Comment 4

[Warner Young]

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.

Comment 5

[Matthew T (active 1999-2002)]

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.

Comment 6

[Akkana Peck]

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?

Comment 7

[Matthew T (active 1999-2002)]

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.

Comment 8

[Andrew Thompson]

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

Comment 9

[Warner Young]

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.

Comment 10

[Frankie]

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.

Comment 11

[Phoenix]

Is this still actual?

Comment 12

[Phoenix]

Resolved per whiteboard