Mouseover occurs outside menu while menu open.




18 years ago
9 years ago


(Reporter: CodeMachine, Assigned: David Hyatt)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




18 years ago
Overview Description:

Mouseovers are passed onto UI elements while menu is open.

Steps to Reproduce:
1) Open a menu and let it stick there.
2) Move the mouse over a personal toolbar button

Actual Results:

Mouseover triggers.

Expected Results:

No mouseover should trigger while the menu is open.  This is intuitive to
me, since mouseover implies you can click it, but you can't here (first click
closes the menu).

Build Date & Platform Bug Found:
1999112216 Win98


18 years ago
Summary: Mouseover buttons within a menu. → Mouseover occurs outside menu while menu open.

Comment 1

18 years ago
Refining summary since I couldn't understand it myself on rereading.  =)


18 years ago
Assignee: trudelle → saari

Comment 2

18 years ago
reassigning to saari for triage, suspecting this could be more than trivial.

Comment 3

18 years ago
This bug report is based on the current behaviour that when the first click
outside a menu falls on a widget or link, that widget or link is not activated
by the *same* click that dismisses the menu. But that appears to be a [4.xP]
bug: in Communicator 4.x, as in other Win32 apps, a click on a widget or link
when a menu is open both activates the widget or link and dismisses the menu.

That bug filed as bug 21390 "[4.xP] Clicking on Widget or link does nothing if
menu open". Obviously fixing that bug would change everything for this bug.

Comment 4

18 years ago
That's an interesting issue.  On NN4 on my Linux box, I can click but get no
mouseover.  Moz is the exact opposite if what you say is true.  I suggest that
you should get mouseover if and only if a click will occur.

I would suggest neither should occur, but the consistency is the most important
issue, even in it is not on 4.x parity, which is probably rather irrelevant
Component: XP Toolkit/Widgets → XPMenus
QA Contact: claudius → sairuh
reassigned QA contact to me & updated component.

Comment 6

18 years ago
I agree that mouseovers outside an active menu should only work if-and-only-if
a click on the region delimited by the mouseover activates something on the
same click that dismisses the menu. That is what I'd prefer - from a UE
standpoint, having to click a link or widget a second time just because
a menu had been open seems an unnecessary inconsistency. Fixing bug
21390 by chaining events or dispatching the same event to two consumers
seems much easier than stopping all mouseovers, everywhere in Mozilla,
as long as a menu is active, at that.

On WinNT, neither 4.x nor IE5 show mouseovers while a menu is active.
I'd say Mozilla is superior in that respect, giving valid feedback to
a user who may be just about to change his or her mind, so long as it is
possible to activate the mouseovering (is that a word?) widget or link.

Not that it would be a disaster not to have the mouseovers so long as a menu
is open, but why throw away valid information if it is valid?


18 years ago
Target Milestone: M13


18 years ago
Target Milestone: M13 → M15
Assignee: saari → german
personally, i think that clicks to get rid of menus or popups should _not_ do
anything (also bug 15640). it's a "cancel" gesture, not an action gesture. IE and
4.x have it right imho. reassigning to german for some UI lovin'

Comment 8

18 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
*** Bug 24649 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
I agree with pinkerton on this one.  When I have a menu open, I'm concentrating 
on that and my pointer should remain as the default pointer (the "arrow" on 
windows).  Clicking anywhere on the window when a menu is open should serve only 
to dismiss that menu.

Comment 11

18 years ago
As I said in bug 21390, I think this is pp. Standard Windows behavior is to treat 
every click as a potential action, even if it's also doing something else like 
closing a menu or bringing a window to the front. Standard on MacOS is just to 
close the menu/bring the window to the front, and not do anything else.

I'm tempted to mark this bug as dependent on 21390, because we should never do a 
mouseover for an item if clicking won't actually do something with that item. To 
do a mouseover but not respond to the click would be unforgivably misleading. 
Therefore, verification of any fix for this bug (if not the fix itself) would 
have to wait for 21390.
Keywords: pp
OS: Windows 98 → All
Hardware: PC → All

Comment 12

18 years ago
You know what, I agree with you (at least I think what I'm doing is agreeing 
with you).  The behavior as it is currently is correct.  Since I can click on a 
link when a menu is open and that link will be followed, the pointer should 
provide the relevant feedback to the user.  So, as far as Windows is concerned 
at least, I think this is behaving properly right now.

Comment 13

18 years ago
There is some good discussion of the bug... but nothing to suggest it should 
preclude branching for the M15 checkpoint.  I'm pushing this to M16 now.
Target Milestone: M15 → M16

Comment 14

18 years ago
even later for M18.
Target Milestone: M16 → M18
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm

Comment 16

18 years ago
See comments for bug 21390 which I just invalidated in favor of fixing this 
mouseover behavior. I have no clue at what level to tackle the problem of 
inhibiting the hover event on a toolbar button when a menu is open, so assigning 
to the peter's team for feedback on how this can be done. Peter feel free to 
reassign back to me once you know the answer or whether this is feasible at all.
removing pp (see explanation in 21390)
Assignee: german → trudelle
Keywords: pp
Whiteboard: nsbeta3

Comment 17

18 years ago
Moving "nsbeta3" to the keywords where it will be seen by the PDT,
and adding "correctness" keyword.
Keywords: correctness, nsbeta3
Whiteboard: nsbeta3

Comment 18

18 years ago
nsbeta3-, I really don't see how this is remotely important enough to be worth
any time/risk for nsbeta3.  As Dean said, when you have a menu up, you're
concentrating on that;  moving the pointer outside for a dismissal click is kind
of an automatic gesture, not something you're carefully following.  I think we
have far too many other problems to fix, much worse ones than this, so this is
just distracting noise.  We need to get this off the radar to focus on the stuff
that really matters.  
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future


18 years ago

Comment 19

18 years ago
*** Bug 48070 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 31302 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
*** Bug 164639 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
->component owner
Assignee: trudelle → hyatt
QA Contact: jrgm → shrir


16 years ago
Blocks: 146242, 147288, 147670
Depends on: 21390
Keywords: mozilla1.2
Whiteboard: [nsbeta3-]


16 years ago
Severity: trivial → normal
Target Milestone: Future → ---

Comment 23

15 years ago
Reference comment 11.  Bug 21390 appears to be fixed.  On win98 at least,
clicking outside a menu now dissmisses the menu *and* acts depedning on where
you clicked.  Therefore, the mouseover effects are now meaningful.  There may
still be issues on other platforms since the behaviour is controlled by prefs
and the defaults are different on Mac and Unix.

Comment 24

15 years ago
Good point.  Marking Invalid, since bug 21390 is the route we're taking.
Last Resolved: 15 years ago
Resolution: --- → INVALID


9 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.