Closed
Bug 21390
Opened 26 years ago
Closed 21 years ago
Clicking on Widget or link does nothing if menu open
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: sidr, Assigned: hyatt)
References
Details
(Keywords: platform-parity)
* 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.
Reporter | ||
Updated•26 years ago
|
Component: UE/UI → XPMenus
QA Contact: elig → sairuh
Reporter | ||
Comment 3•26 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 elig@netscape.com for UE perspective.
Over in bug 20016 matty@box.net.au 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.
Reporter | ||
Updated•26 years ago
|
Assignee: shuang → saari
Reporter | ||
Comment 4•26 years ago
|
||
Sorry for the spam, forgot to assign to new component.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13
Reporter | ||
Updated•26 years ago
|
OS: Windows NT → All
Hardware: PC → All
Reporter | ||
Comment 5•26 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.
Updated•26 years ago
|
Target Milestone: M13 → M15
Updated•25 years ago
|
Assignee: saari → german
Status: ASSIGNED → NEW
Comment 6•25 years ago
|
||
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'
Reporter | ||
Comment 7•25 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.
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 10•25 years ago
|
||
*** Bug 24323 has been marked as a duplicate of this bug. ***
Updated•25 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
Comment 12•25 years ago
|
||
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
Reporter | ||
Comment 13•25 years ago
|
||
*** Bug 32819 has been marked as a duplicate of this bug. ***
Comment 14•25 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
Reporter | ||
Comment 16•25 years ago
|
||
*** Bug 38426 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
*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•25 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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 19•25 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
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•24 years ago
|
||
*** Bug 79303 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
*** Bug 84924 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 93495 has been marked as a duplicate of this bug. ***
Comment 23•24 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•23 years ago
|
||
*** Bug 131951 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
um, ie5.5w2k activates the link. I think mpt clearly defined the behavior.
Severity: minor → normal
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Target Milestone: M18 → ---
Updated•23 years ago
|
Severity: normal → minor
Target Milestone: --- → Future
Comment 27•23 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•22 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?
Comment 29•21 years ago
|
||
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040207
Status: NEW → RESOLVED
Closed: 25 years ago → 21 years ago
Resolution: --- → WORKSFORME
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.
Description
•