Closed Bug 32494 Opened 24 years ago Closed 12 years ago

Menus don't act like real Mac menus (should disappear on mouse up after dragging mouse out)

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mpt, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox]) 

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
Keywords: pp
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.
No longer blocks: 52023
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.
Keywords: pp
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)
Keywords: nsdogfood
Keywords: nsCatFood
Keywords: nsdogfood
Sorry, but we can't afford this level of polish right now.  ->0.9.3/helpwanted
Keywords: 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?
Depends on: 78249
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.
Target Milestone: mozilla1.0 → mozilla1.0.1
--> default owner
Assignee: dean_tessman → hyatt
Nominating for next release.  This has been open and annoying for over a year now.
Keywords: nsbeta1
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
->jag
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 → ---
Depends on: 66254
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
Assignee: jag → nobody
Is this still actual?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 12 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.