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

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

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

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.

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 anyway.

reassigned QA contact to me & updated component.

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?

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'

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

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

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.

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.

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.

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.

even later for 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.

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)

Moving "nsbeta3" to the keywords where it will be seen by the PDT, and adding "correctness" keyword.

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.

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

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

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

->component owner

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.

Good point. Marking Invalid, since bug 21390 is the route we're taking.