Closed
Bug 5927
Opened 26 years ago
Closed 24 years ago
Nested-menu selection is too hard, let's go shopping.
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: paulmac, Assigned: hyatt)
References
()
Details
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.
Comment 1•26 years ago
|
||
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)
Comment 2•26 years ago
|
||
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.
Comment 3•26 years ago
|
||
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?
Assignee | ||
Comment 4•26 years ago
|
||
250 milliseconds.
Reporter | ||
Comment 5•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M10
Comment 7•26 years ago
|
||
Targeting M10
Updated•26 years ago
|
Target Milestone: M10 → M13
Comment 9•26 years ago
|
||
This is a native menu implementation issue, so I'm moving it out past dogfood.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Comment 10•25 years ago
|
||
mass moving m14 bugs to m15
Updated•25 years ago
|
Comment 11•25 years ago
|
||
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
Comment 12•25 years ago
|
||
*** Bug 19495 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
Define what you mean by "the mouse pointer coming to a stop" without talking
about time delays.
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
... 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.
Comment 19•25 years ago
|
||
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?
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
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.
Reporter | ||
Comment 22•25 years ago
|
||
dividing up phillips bugs, he no longer works here
Comment 23•25 years ago
|
||
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.
Updated•25 years ago
|
Component: XP Toolkit/Widgets → XPMenus
Comment 24•25 years ago
|
||
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/>
Comment 25•25 years ago
|
||
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.
Comment 27•25 years ago
|
||
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
Comment 29•25 years ago
|
||
updating summary so i remember what this bug is.
Summary: Nested-menu selection has incorrect behavior → Nested-menu selection is too hard, let's go shopping.
Comment 30•25 years ago
|
||
*** Bug 25996 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•25 years ago
|
||
I'm making this bug my bitch.
Assignee: pinkerton → hyatt
Status: ASSIGNED → NEW
Assignee | ||
Comment 32•25 years ago
|
||
Nailed to the wall, baby.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 33•25 years ago
|
||
verif w/opt comm bits [2000021708] on linux and winNT.
Status: RESOLVED → VERIFIED
Comment 34•24 years ago
|
||
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.
Status: VERIFIED → REOPENED
OS: Windows 95 → Mac System 9.x
Hardware: PC → Macintosh
Resolution: FIXED → ---
Summary: Nested-menu selection is too hard, let's go shopping. → Nested menus are still too hard, let's go shopping some more
Comment 36•24 years ago
|
||
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.
Updated•24 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
OS: Mac System 9.x → Windows 95
Hardware: Macintosh → PC
Resolution: --- → FIXED
Summary: Nested menus are still too hard, let's go shopping some more → Nested-menu selection is too hard, let's go shopping.
Comment 37•24 years ago
|
||
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.
Comment 38•24 years ago
|
||
There's a difference between QA and design...
Updated•24 years ago
|
QA Contact: sairuh → jrgm
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Comment 40•16 years ago
|
||
I am sorry for my rude tone in comments 34 and 37. It was unhelpful.
You need to log in
before you can comment on or make changes to this bug.
Description
•