21390 - Clicking on Widget or link does nothing if menu open

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Sean Richardson]

* 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

[Sean Richardson]

Sorry, the bug that is the DUP is bug 21353, not 21535!

Comment 2

[Sean Richardson]

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

Comment 3

[Sean Richardson]

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 [e-mail] for UE perspective.

Over in bug 20016 [e-mail] 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.

Comment 4

[Sean Richardson]

Sorry for the spam, forgot to assign to new component.

Comment 5

[Sean Richardson]

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.

Comment 6

[Mike Pinkerton (not reading bugmail)]

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

[Sean Richardson]

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

[leger]

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

Comment 9

[Peter Trudelle]

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

Comment 10

[Peter Trudelle]

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

Comment 11

[leger]

Setting the keyword all open [4.xp] bugs to 4xp.

Comment 12

[Matthew T (active 1999-2002)]

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.

Comment 13

[Sean Richardson]

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

Comment 14

[Jim Roskind]

This doesn't seem like something that is blocker branching of the M15 
checkpoint, so I'm now pushing this to M16.

Comment 15

[shuang (gone)]

move even later: M18.

Comment 16

[Sean Richardson]

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

Comment 17

[sairuh (rarely reading bugmail)]

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

Comment 18

[german]

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.

Comment 19

[Sean Richardson]

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

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

Comment 20

[Blake Ross]

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

Comment 21

[Matthew T (active 1999-2002)]

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

Comment 22

[:deanis74]

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

Comment 23

[Ben Ruppel]

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

[John Levon]

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

Comment 25

[timeless]

um, ie5.5w2k activates the link.  I think mpt clearly defined the behavior.

Comment 26

[timeless]

.

Comment 27

[Akkana Peck]

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

[Ian Nartowicz]

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?

Comment 29

[Simon Paquet [:sipaq]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040207