Clicking on Widget or link does nothing if menu open




19 years ago
11 years ago


(Reporter: sidr, Assigned: hyatt)



Windows 95

Firefox Tracking Flags

(Not tracked)




19 years ago
* Overview:
In Mozilla, if  a context, toolbar, or menubar menu is open when the user
clicks on a widget or a link, the menu dismisses but the widget or link does
not activate. In Communicator 4.x, as with other Win32 apps, the widget or
link activates at the same time as the menu dismisses. Unknown what is expected
on other platforms.

* Steps to reproduce:
1. Activate any menu.
2. Move the mouse pointer away from the menu without bringing up another
   menu (it may be necessary to slide the mouse pointer off the bottom)
3. Click on any Widget or Link.

* Actual Result:
The menu dismisses, but the widget or link is not activated.

* Expected Result:
The menu dismisses, and the widget or link is activated.

* Tested with:
1999-12-09-08-M12 nightly binary on Windows NT 4.0sp3
1999-12-09-08-M12 nightly binary on Windows 98 SE

* Additional Information:
Fixing this bug is mutually incompatible with fixing bug 20016 "Mouseover
occurs outside menu while menu open", new in "XP Toolkit/Widgets". In that
bug, mouseovers are undesired while a menu is active since clicking on
a widget only dismisses the menu, and mouseovers imply a working UI element.
If this bug is fixed, then bug 20016 no longer will exist as reported.
On the other hand, if this bug is not fixed, bug 20016 will continue to
be a UE bug.

Bug 21535 "Clicks to Win32 widgets that dismiss menus not passed to Windows"
is actually a special case of this bug. (I know, I should have checked to
see if the general case existed before filing a bug on the specific).
Marking 21535 as a DUP, but it should be checked before verification to
make sure that it does not need to be reopened.

This bug looks like an "Event Handling" bug, but passing first to "UE/UI"
for the decision as to whether this bug or bug 20016 should be fixed.
I would very much advocate this bug.

Comment 1

19 years ago
Sorry, the bug that is the DUP is bug 21353, not 21535!

Comment 2

19 years ago
*** Bug 21353 has been marked as a duplicate of this bug. ***


19 years ago
Component: UE/UI → XPMenus
QA Contact: elig → sairuh

Comment 3

19 years ago
Changing Component to new "XPMenus" from "UE/UI" to match bug 20016
since fixing both makes no sense, and this does look like an XPMenus
problem. Cc-ing for UE perspective.

Over in bug 20016 comments that 4.x parity is less
important than consistency: not showing a mouseover outside a menu if
a single click cannot activate the widget or link that the mouseover
calls attention to. While the latter *is* important, the parity would not
be just with 4.x, but with all Apps, at least on Win32, and from what Matty
says, possibly on at least some Window Managers on Linux.

On Win32, mouseovers do not happen in any App's (including Communicator and IE5)
toolbars while a menu is open, but a click on a widget outside the menu will
always activate that widget as well as dismissing the menu.

I don't know about this on the Mac or on Xwindows in general, but doing
otherwise would force the user to click a second time on a widget or link
if a menu is open, so fixing this bug seems like sound XP UE practice ...
unless users of some OS or on some Platform rely on needing to click twice.


19 years ago
Assignee: shuang → saari

Comment 4

19 years ago
Sorry for the spam, forgot to assign to new component.


19 years ago
Target Milestone: M13


19 years ago
OS: Windows NT → All
Hardware: PC → All

Comment 5

19 years ago
Tested this quickly on Linux Slackware 4, unknown Window Manager.
NN 4.7 activates a widget or link with the same click that dismisses a
window; the Mozilla M11 release does not. Unknown on Mac or other Unices,
but changing Platform/OS from "PC/WinNT" to "All/All" on educated guess.


19 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 7

19 years ago
I agree that NN 4.7 and IE5 do this right, but in both cases, any object
under the click that dismisses the menu is activated, if it can be, by the
same click. If the user prefers that click to *only* dismiss the menu,
all that is necessary is to click on dead space on the page, or press ESC
(once bug 20019 is fixed).

I can sympathize with the position in bug 15640, from the point of view of the
user new to the web who has not yet learned how to make an educated guess
where the dead space is. And I've been caught by this myself, despite knowing
where <A> elements are likely to be lurking, by a slip of the mouse or just
carelessness, and had to click on the [Back] button quickly. But making a
click on a link or widget work differently if a menu is up is just as sure to
annoy experienced users, used to the [4.xP] behaviour.

Comment 8

19 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 9

19 years ago
*** Bug 24323 has been marked as a duplicate of this bug. ***

Comment 10

19 years ago
*** Bug 24323 has been marked as a duplicate of this bug. ***

Comment 11

19 years ago
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp


19 years ago
Summary: [4.xP] Clicking on Widget or link does nothing if menu open → Clicking on Widget or link does nothing if menu open
This is *not* 4xP on MacOS (that is, MacOS 8.0 and higher, which have sticky 
menus). Click on a menu title, move the pointer through the menu and off the 
bottom, and then click on a link in the Web page while the menu is still open. 
The menu closes, and nothing else happens.

This is analagous to clicking on a link in a non-frontmost window in MacOS; the 
window comes to the front, but nothing else happens. Clicking on a link in a
non-frontmost window in Windows, however, activates the link.

As usual (not as always, but as usual), I think that MacOS has it right here: by 
clicking outside a menu(/clicking in a non-frontmost window), you're more likely 
to be wanting just to close the menu(/bring the window to the front) than to 
actually do anything else in the same click.

But I also think platform parity is more important in this case than 
philosophizing about which platform's behavior is best. So, adding pp keyword, 
and marking as Windows only.
Keywords: pp
OS: All → Windows 95

Comment 13

19 years ago
*** Bug 32819 has been marked as a duplicate of this bug. ***

Comment 14

19 years ago
This doesn't seem like something that is blocker branching of the M15 
checkpoint, so I'm now pushing this to M16.
Target Milestone: M15 → M16

Comment 15

19 years ago
move even later: M18.
Target Milestone: M16 → M18

Comment 16

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

19 years ago
BTW on Win32 IE5.5 clicking on a link while the menu is open does nothing also. I 
do not think there is a hard rule how windows apps should behave here, on the mac 
it is much clearer. 
I find it much preferrable for our audience to interpret the outside click as a 
menu cancel gesture.
I do not see a problem with this behavior on all platforms as long as we are not 
suggestion that a button can be clicked by showing a mouseover hilite. (bug 
20016). I suggest we close this bug and focus on trying to fix the behavior in 
20016 instead. Marking invalid.
Last Resolved: 19 years ago
Resolution: --- → INVALID

Comment 19

19 years ago
There is another side effect of not triggering any action on the same click
that dismisses a menu: the onmouseup event, which would have triggered the
action, is not consumed (see bug 40068). In most cases I'd expect this to be 
both innocuous and invisible to the user, but this could confuse some javascript

Also, it seems reasonable that the decision to only cancel menus would apply
equally to context menus,  but context menus have not been mentioned to date 
in this bug. German, context menus are included under the rubric "menus", right?

Finally, while it makes sense to make a clean break from 4.x behaviour in the 
modern UI where it will enhance usability, failing to trigger actions in the
page canvas with the same click that dismisses a menu may actually be confusing
when using the classic [Windows] UI. A 4.x-alike chrome that is only (forgive 
the pun) skin deep when it comes to behaviour details like this may not be well 

Comment 20

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

Comment 22

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

Comment 23

18 years ago
Why is this still invalid?  IE6.0 and explorer in winXP activate the widget/link
(even though they don't do mouseovers, part of that other bug).  Didn't mpt
reccommend platform parity?

Comment 24

17 years ago
*** Bug 131951 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
um, ie5.5w2k activates the link.  I think mpt clearly defined the behavior.
Severity: minor → normal
Resolution: INVALID → ---
Target Milestone: M18 → ---

Comment 26

17 years ago
Assignee: german → hyatt
QA Contact: jrgm → shrir


17 years ago
Blocks: 20016


17 years ago
Severity: normal → minor
Target Milestone: --- → Future

Comment 27

16 years ago
On linux, at least, a big part of the problem is that you can't do anything in
ANY window as long as moz has a menu open.  It wouldn't be so bad if it was just
restricted to the moz window.

Comment 28

16 years ago
This WFM now (2003012709) on win98.  I believe that the behaviour for the click
to do nothing is correct on Mac and Unix platforms in accordance with bug 66834
comment 77.  Can this bug be closed?

The only remaining issue seems to be comment 27, which seems like a related but
more serious issue.  I know this has been mentioned elsewhere but couldn't find
a specific bug for it.  Perhaps it should be raised as its own bug?
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040207
Last Resolved: 19 years ago15 years ago
Resolution: --- → WORKSFORME


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