Build: 2000031908, MacOS 8.6 To reproduce: * Open Navigator. * Hold the mouse down on the `Open Windows' button. * Drag the pointer off the button, to somewhere other than the opened menu. What should happen: * The menu should disappear. It should reappear if the pointer returns to the menu title during the current drag. What actually happens: * The menu stays visible -- even after the mouse button is released, until the mouse is clicked again.
this is how menus behave on the mac menubar. of course the menu stays open when the mouse has left the "open windows" button, or the mouse is released. What is the difference here?
No, this isn't how menus behave on Mac. If a menu title is just clicked on Mac, then it stays open -- even if I then move the mouse outside the menu (unless I move it elswhere on the menu bar, in which case the menu closes). Fine. But if the menu title is dragged -- even if I never go outside the menu title during the drag -- the menu closes as soon as I mouse up. This doesn't happen with the XPToolkit menus. The usefulness of this is that a drag tells the menu `ok, I'm going to make a drag selection, rather than a click-click selection'. Then if the drag doesn't mouse up on a menu item, the menu says `ok, you've changed your mind about using me, so I'll go away now'. It saves the user from having to find a `safe' place to click to close the menu. Windows menus don't behave this way, so feel free to mark this as pp if you think it shouldn't be implemented XP. Resummarizing for clarity.
Summary: Menu doesn't disappear after dragging off header → Menu doesn't disappear after dragging menu title
ok, yo comprendo. accepting for post-beta2
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Mass move of all M20 bugs to M30.
Mass moving M20 bugs to M30
Target Milestone: M20 → M30
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
*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
this is annoying, esp on mac. GTK dismisses on mouseup, the jury seems out on whether win32 does (some apps do, some don't), so I'll make it do the same everywhere.
Summary: Menu doesn't disappear after dragging menu title → Menu doesn't disappear on mouse up after dragging menu title
Target Milestone: Future → mozilla0.9
What Windows apps behave this way? I've tried "standard" menus under NT and 2000, as well as the "menus" that MS has cooked up and included in their new apps. Never does releasing over a disabled menu item dismiss the menu. Things behave properly as they are on Windows. Fix this on other platforms, but leave Windows alone.
all regular standard NT menus do this, even the iconic window menu. the new msft IE/MSDN menus don't do this. running win2k.
Target Milestone: mozilla0.9 → Future
oops m0.9 Dean: wordpad, notepad, palm desktop, etc all work this way.
Target Milestone: Future → mozilla0.9
cc'ing dean this time, so my argument isn't in a vaccuum.
Sorry Mike, I mis-read this based on your comment in bug 52023. I'll put comments in over there. I assume that what you're referring to is something like, using Notepad: 1. Click and hold on the Help menu 2. Drag mouse to blank menu bar are to the right of the Help menu Result: Menu dismisses. Agree 100% with this behavior. Didn't realize that Mozilla didn't work this way.
In Win2000, the standard menus behave this way, but MS has once again screwed with standard behavior in implementing their menus, which behave differently. Going with standard Windows behavior makes this xp, not pp. Removing [pp] keyword.
Target Milestone: mozilla0.9 → mozilla0.9.1
*** Bug 70667 has been marked as a duplicate of this bug. ***
Should this go back to Platform all and OS all?
nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)
Sorry, but we can't afford this level of polish right now. ->0.9.3/helpwanted
Target Milestone: mozilla0.9.1 → mozilla0.9.3
drat, won't get to this.
Target Milestone: mozilla0.9.3 → mozilla1.0
Gimme. I assume you won't complain about my taking this, right Mike?
Assignee: pinkerton → dean_tessman
Status: ASSIGNED → NEW
This would be so much easier if I could write an IsMouseInMenu() function. Need bug 78249 fixed for that. It's currently targetted for 1.1, but I'll try to convince Hyatt to drop that a bit. Can we change this to All/All?
Note to self: look at nsToolbarDragListener::ItemMouseIsOver.
Note that this also affects bookmark folders in the toolbar. Click-and-hold on a menu, drag to any area outside the menu below the menu bar, release: Mac OS: menu disappears Notepad on Win2k: menu disappears MSIE on Win2k: menu remains KDE: menu disappears Mozilla: menu remains Click-and-hold on a menu, drag to a blank area of the menu bar: Mac OS: menu disappears Notepad on Win2k: menu remains MSIE on Win2k: menu remains KDE: menu remains Mozilla: menu remains Release on a blank area of the menu bar: Mac OS: nothing (menu was already gone) Notepad on Win2k: menu disappears MSIE on Win2k: menu remains KDE: menu disappears Mozilla: menu remains Menus in most Windows apps behave like menus in Notepad. Interestingly, the Favorites menu in MSIE behaves like menus in Notepad. I submit that menus in Mozilla should behave like standard Mac menus when running on Mac OS, and should behave like Notepad and KDE when running on all other platforms (unless somebody knows of some other platform on which menus normally behave differently?). Note that Mac OS uses the system menubar, but there are other places where menus occur: bookmark folders in the toolbar, popup menus in Preferences, OPTION menus in forms, etc.
--> default owner
Assignee: dean_tessman → hyatt
Nominating for next release. This has been open and annoying for over a year now.
Peter, I hope you don't mind me reassigning this from hyatt's list. Is there a better assignee to whom you could "gift" this bug? I figure you will want to triage it sooner or later, and waldemar's got a point about how long it has lain dormant except for Dean's good work (Dean, did you get close and give up because you weren't getting reviews for other patches? I hope not -- anyway, if you have any work-in-progress on this that's not attached, please lay it on us). /be
Assignee: hyatt → trudelle
Assignee: trudelle → jaggernaut
nsbeta1- per Nav triage team
Keywords: nsbeta1 → nsbeta1-
1 year later... Some of the menus that exhibit this behavior are: Toolbar menus Select/Option HTML menus Character coding menu in Preferences (see bug 117208) The actual system Menu Bar works correctly.
OS: Mac System 8.5 → MacOS X
Summary: Menu doesn't disappear on mouse up after dragging menu title → Menus don't act like real Mac menus (should disappear on mouse up after dragging mouse out)
Target Milestone: mozilla1.0.1 → ---
Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 I have noticed unusual menu behaviour running on WinXP: 1. Click-and-hold on a menu. Release mouse elsewhere on the screen or on a blank area of the menu bar. I would expect the menu to disappear but it doesn't. I believe that I am agreeing with Comment #23 from Andy. 2. I have created a number of sub-folders within the bookmarks toolbar folder so that they appear (as folders) within the toolbar. WITHIN these folders I have more sub-folders. If the mouse hovers over these folders the contents are automatically displayed. All well and good. However, if I right-click at this point to get a context menu (I wanted to choose "Manage Folder") the contents of that folder remain visible until either a) I close Mozilla/Firebird or b) I select an item from that folder This has a number of annoying side effects--I am not able to complete forms while the orphaned folder is still displaying and the folder remains "on top" of any other application that I switch to.
Firefox 1.5 still has this problem: - Popup menus in Preferences - Folders in the Bookmark toolbar - <select> menus in forms - Click-and-hold/right-click/click-the-tiny-arrow on Back/Forward buttons This is not a Mac-specific bug! The desired behavior is standard on other platforms (with some application-specific inconsistency on Windows). Please change the Hardware/OS fields to All and fix the summary. :-)
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Is this still actual?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?]
Resolved per whiteboard
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?] → [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.