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)

All
Windows 95
defect

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.
Sorry, the bug that is the DUP is bug 21353, not 21535!
*** Bug 21353 has been marked as a duplicate of this bug. ***
Component: UE/UI → XPMenus
QA Contact: elig → sairuh
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.
Assignee: shuang → saari
Sorry for the spam, forgot to assign to new component.
Status: NEW → ASSIGNED
Target Milestone: M13
OS: Windows NT → All
Hardware: PC → All
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.
Target Milestone: M13 → M15
Assignee: saari → german
Status: ASSIGNED → NEW
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'
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
*** Bug 24323 has been marked as a duplicate of this bug. ***
*** Bug 24323 has been marked as a duplicate of this bug. ***
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
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
*** Bug 32819 has been marked as a duplicate of this bug. ***
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
move even later: M18.
Target Milestone: M16 → M18
*** 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
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
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.
*** Bug 79303 has been marked as a duplicate of this bug. ***
*** Bug 84924 has been marked as a duplicate of this bug. ***
*** Bug 93495 has been marked as a duplicate of this bug. ***
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?
*** Bug 131951 has been marked as a duplicate of this bug. ***
um, ie5.5w2k activates the link. I think mpt clearly defined the behavior.
Severity: minor → normal
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Target Milestone: M18 → ---
.
Assignee: german → hyatt
Status: REOPENED → NEW
QA Contact: jrgm → shrir
Blocks: 20016
Severity: normal → minor
Target Milestone: --- → Future
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.
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
Status: NEW → RESOLVED
Closed: 25 years ago21 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.