It is a little difficult to select items on nested menus, due to some incorrect event handling. This is a little hard to describe, so bear with me. To duplicate: Goto the Debug - Verification menu item. Semi-quickly drag your mouse from the middle of the Verification menu item diagonally down to the Microsoft menu item in the nested menu. Notice that the two menu items below verification (Viewer Demos and XP Toolkit) are quickly selected and de-selected, with the Verification menu eventually ending up selected. However, the Microsoft nested menu item is NOT selected, although it should be. There should be some delay during the mouse drag, where the items below the Verification menu item are not selected, which is probably causing the confusion. The behavior is observed on 5/4 M5 builds on win95. By contrast, the Mac seems to have the correct behavior. Feel free to call me if I've thoroughly confused you.

Well the Mac doesn't even do dynamic menus yet. I think I know what you're talking about, but I'm not sure. I'll take a look when I'm infront of my PC again (meeting)

If you play with the Mac menus note that it has nothing to do with a time delay... it is based on the drag vector. Go straight down quickly and you switch submenus. Go diagonally, still staying within the parent menu, and then you see a pause. Arbitrarly adding a time delay to submenu construction will make all submenus feel slower, no matter what you do. I don't really like that solution, although it looks like that is how things are done in Win32, so I guess I'll do that for Win.

Windows sucks. I'm getting the select messages for the menu items before the deselect message for the submenu. So I guess I have to add in some timer code to make up for this and not really fire the construction event immediately. What a pain in the butt. So how many milliseconds should the delay be?

250 milliseconds.

Looking at windows (on Comm. 4.5) a little more closely, it looks like the top-level menu selection on seamonkey is actually ok, the problem is that you can no longer select any items on the nested menu, even though the top-level menu (in this case Verification), is reverted back to being selected after dragging over the ones below it. So I don't think a delay is needed, just something to tell the nested menu that it can be selected. Of course, not being a coder, I could have no idea what I'm talking about.

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

Targeting M10

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

This is a native menu implementation issue, so I'm moving it out past dogfood.

mass moving m14 bugs to m15

From bug 19495: BUILD: M11 TO REPRODUCE: Start Mozilla. Select the `File' menu, then the `New' submenu. Move the mouse pointer diagonally south-east to select `Message'. WHAT HAPPENS: The submenu disappears. WHAT SHOULD HAPPEN: See URL. The sub-menu should persist until the user spends more than about 1 second on any other main menu item. (That's more than about 1 second on any other *particular* menu item, not 1 second on other menu items in total.) Only then should the menu system assume that you're interested in another main menu item, close the submenu, and start highlighting other main menu items. This allows the user to go from the main menu item to the sub-menu item in a straight line, rather than following a non-intuitive inverted L shape. If the mouse button is released (or clicked) on another main menu item while the submenu is still open, however, the menu system should recognize that it was not the submenu they were interested in, close the submenu, highlight the selected main menu item, then close the menu and perform the relevant command. Additional keywords: submenu, hierarchical menu

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

By the way, it's not a native menu implementation issue as saari suggests: these are XPToolkit menus, and the same delay should be built in to the implementation on all platforms.

The time delay solution should not be considered a "bad thing". Looking at it another way, during this mouse motion there is a clear ambiguity in what the user is intending and the delay simply is the UI waiting to see what the user intended. This is natural feeling. However, it can be improved! Because if the mouse pointer should come to a stop, you can dispense with any remaining delay (or most of it) and go with what is under the mouse pointer at that moment. It'll seem natural.

Define what you mean by "the mouse pointer coming to a stop" without talking about time delays.

I've already defined `coming to a stop' as spending more than one second on any other single menu item. On reflection, this is probably too long -- half a second would be enough.

mpt's algorithm sounds like it would work very well. Of course, the timeout should be tunable (hidden pref?) If the timeout is set to be very long, then the effect would be like Motif (and Be?) menus, where you click rather than hover to bring up a submeny, and the submenu stays posted until you click somewhere else. I've been idly working on code to do this in my spare time, but it's not working very well yet (not enough spare time :-) and mpt's algorithm would solve both problems at once.

... And Akk becomes the latest person to succumb to YAPS (Yet Another Pref Syndrome). No, this needn't and shouldn't be a pref. Just get in the usability lab, find out the delay length which works best (it should be the same for all humans, which is why it shouldn't be a pref), and implement it.

It's definitely not the same for all humans. For instance, in Windows, some people like the delay on all menus popping up, whereas others can't stand it and use TweakUI to change the delay. In Unix, some people like the Motif style (nothing pops up unless you click somewhere, nothing pops down unless you click somewhere) while apparently others like the windows style. It's trivial to add one integer pref for delay time, so why not give the user that option?

Only one reason: if the pref accidentally got set to a horrible value, it would be extremely difficult for the average user to (a) work out why they didn't like the way the menus worked, (b) realize that there was a hidden pref for it, and (c) be able to set the pref, to a number which represented their preferred behaviour. How good this reason is is obviously open to debate.

Following up the comment made by dw@play.net 11/21/99 13:45 - Surely this would be more trouble to implement than a simple timer, but what about treating "coming to a stop" the same way a human would - something like, "no movement of the mouse pointer more than a few px within 50-80ms, and any movement is all within one menu item region" (The "few px" was a GUI-tunable parameter for double-clicking positioning accuracy back in Windows 3.1.) Alternatively, mousing velocity (or delta-v, whichever is easier) could be measured over suitable intervals (tens of ms) and when it stays near or at zero for more than one sample, the selection could be indicated. At that point, the user is pausing if not stopped over a particular item and there is no harm in showing it as selected, even if the user later moves on. This would keep other items from showing as selected just because they were on the path to the intended item, without slowing down those who prefer to operate their GUIs as fast as feedback will allow. (The diagonal works only if used reasonably quickly, anyway). As far as suitable delays go: what I'd consider a suitable delay near the end of an all-nighter after a full day would not match what I'd choose just after a vigorous bike commute following a healthy breakfast first thing in the morning! - and I know I'm not alone there.

dividing up phillips bugs, he no longer works here

Following up on something that akanna mentioned, I use TweakUI to adjust my menu speed in Windows. I like my menus to popup much quicker than the default. But if I set that setting, I expect it to apply to all applications. If I set something in a general location (eg. menu speed, window colors, etc.), it should apply to everything. If I someday want my menus to popup slower, am I going to have to change the TweakUI setting and then go into 20 different apps that ignore that setting and set it there as well? I hope not. Of course, I'm speaking only from a Windows perspective. Different behavior under Motif behavior was also alluded to earlier.

The GNOME project is currently considering these UI suggestions: > > 7. Set a user-configurable delay time (aka hysteriesis) before opening > submenus (so you can move through an entire menu quickly without opening all > the submenus). It should default to 1/2 a second. >... > 20. Change the mouse behavior in menus, so when a submenu is opened, an > invisible triangle is drawn between the mouse cursor on the menu item, the > top-left and bottom-left corners of opened submenu, and the submenu stays open > so long as the mouse cursor is within the triangle. <http://developer.gnome.org/gnome-ui/software/widgets/>

Gnome recommendation 20 sounds good and would make menus much easier to use, but doesn't it still have to have a delay? If you move to a menu that pops up a submenu, then move to the next menu item down, and stop there, you'd expect the submenu to go away eventually (unless you're using the "click makes the submenu stay up" model that Motif, Be and others use, which is much easier to understand than the delay-based models). Rec. #7 isn't as important to me, because it's the lack of delay in *closing* a submenu, not in opening one, that bothers me. A delay in *opening* submenus when there's no other submenu already open just makes the UI look slow and unresponsive.

Taking menu/popup bugs.

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.

bulk accepting xpmenu/popup bugs. sigh.

updating summary so i remember what this bug is.

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

I'm making this bug my bitch.

Nailed to the wall, baby.

verif w/opt comm bits [2000021708] on linux and winNT.

Ok. The way this was fixed sucks bad. It was fixed the same way as native Windows submenus work, but native Windows submenus suck bad too. 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. My previous comments in this bug are all wrong (even though I pointed to an URL which explained it right), and I'm really really sorry. 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. (Note, contrary to what the URL states, it's not 1500 ms; I checked it with a stopwatch several times.) 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.

oh man. you've got to be kidding.

Sure thing, Matt, go ahead and code it. This should be a separate bug and this bug should be marked back to fix, as the original symptoms have been addressed.

Um, Dean, you stick to coding, I'll stick to QA, and Mozilla will be the better for it, okay? Split off bug 66254. Re-marking fixed.

There's a difference between QA and design...

bonk.

I am sorry for my rude tone in comments 34 and 37. It was unhelpful.