Closed Bug 21296 Opened 25 years ago Closed 18 years ago

Can't use Mac menu bar with a menuless window (or modal dialog) in front

Categories

(Core :: XUL, defect, P2)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: sfraser_bugs, Assigned: jaas)

References

Details

(Keywords: arch) 

When the preferences dialog is up, I can't use the menu bar at all; click are
ignored. When a modal dialog is up, the following menus _should_ be active:
Apple menu
Edit menu (if editing operations are permitted)
Help menu (e.g. Show balloons)
Menus on the RHS of the menu bar -- e.g. application menu
Component: XP Toolkit/Widgets → XPMenus
QA Contact: claudius → sairuh
reassigned QA contact to me & updated component.
Status: NEW → ASSIGNED
Target Milestone: M13
*** Bug 5122 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → All
Hardware: Macintosh → All
had checked with y'day's builds (1999121609 for win and mac, 1999121608 for
linux) and this affects all platforms. updated platform/os fields.
Assignee: saari → danm
Status: ASSIGNED → NEW
Tossing to Dan, who thinks this should be easy to fix.
Hardware: All → Macintosh
How can this affect all platforms? Yes, you can't get to a menubar inside another window
with a modal window up, but that's not a bug. This is a *bug* only on the Mac.
Assignee: danm → sdagley
Target Milestone: M13
We got problems with this one. Earlier comments that this would be easy were
ill conceived. Allowing mousedowns in the menubar while a modal dialog is up
is trivial. Hooking up a menubar to each modal dialog is a real problem, here in
our Windows-centric, a-menubar-in-every-window architecture.

The favourite solution suggested so far was to add a Mac-platform-specific overlay
to the affected dialogs, giving them a Cut/Copy/Paste menubar to call their own.
This is an unhappy solution, though, because a dialog's modality isn't built-in,
while this menubar would be, so there will be an unnatural coalition between the
two, easily broken.

A less fragile solution would involve teaching menubars to speak to other windows
and teaching windows to disable inapplicable commands in the current menubar
when they come to the front. All concepts straightforward to the Mac, but foreign
to our current, Windows-based design.

Concluding, there are some architectural issues here. While I agree this is a completely
"beta"-worthy problem, it won't be solved in time.

Reassigning to the new menu czar for safe-keeping. Let's collaborate when the day comes
to knock this one down.
Not only Cut, Copy, and Paste, but also:
* Edit > Undo and Edit > Redo (Ben Goodger has these implemented on a global
  scale, IIRC)
* File > Close (== Cancel, so perhaps it could be built into the Ok/Cancel
  overlay??)
* /everything/ in the Help menu, not just balloon help

These functions should be available on all platforms: on Windows and X this
would be through their shortcuts (^W, ^Z, ^Y, ^X, ^C, ^V, and ^?/F1), but on Mac
they should also be accessible from the menu bar.
Status: NEW → ASSIGNED
Target Milestone: M15
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
Passing the menu bug torch to pinkerton
Assignee: sdagley → pinkerton
Status: ASSIGNED → NEW
this is not an xp menu bug, as far as i can tell. passing back to owner of mac 
native menus, saari.
Assignee: pinkerton → saari
Note I can reproduce this on Linux ID 2000021616. So there is some
platform independence about it.

In fact I think this is actually the bug that cause #22049 to have such bad
effect. If a site is spitting dialog boxes at you there is nothing you can do to
get away from it. Therefore all the navigation tools (i.e. most of the menubar
and the toolbar) should still work when a dialog box is popped up).

Jan

*** Bug 31097 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: P3 → P1
Well, here we are again, and I don't have any better ideas for this bug.
Platform specific overlay?

Well, danm wrote:
>
> The favourite solution suggested so far was to add a Mac-platform-specific
> overlay to the affected dialogs, giving them a Cut/Copy/Paste menubar to call
> their own. This is an unhappy solution, though, because a dialog's modality
> isn't built-in, while this menubar would be, so there will be an unnatural
> coalition between the two, easily broken.

However, I really don't think this is an issue. The menu bar should work with all 
dialogs on Mac, whether modal or not. Other windows (bookmarks, address book, 
etc) have their own menus, so why not have a generic menu overlay for dialogs?

That wouldn't be quite the same as the usual Mac behavior of just disabling all 
irrelevant items from the menus of the dialog's parent window. In other words, 
there would be some jumping around in the menu bar as you went in an out of a 
dialog, jumping around which you wouldn't get in a normal Mac app. But that would 
still be a whole lot better than nothing.

*** Bug 33205 has been marked as a duplicate of this bug. ***
*** Bug 33202 has been marked as a duplicate of this bug. ***
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
Downgrading priority, too many other things popping up.
Priority: P1 → P2
I'm not getting to this in beta2
Target Milestone: M16 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
*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
Summary: Can't use menu bar when a modal dialog is up → Can't use Mac menu bar when a modal dialog is up
I don't think I'll get to this in beta3 either

That worries me greatly. For users who can't use key shortcuts (i.e. lots of 
naive ones), they'll not be able to Cut/Copy/Paste, becuase there are no menus 
active. I'm gonna put nsbeta3 in, and see what the team think. Sorry Chris.
Keywords: nsbeta3
Team thinks it will affect very few users, and is not worth the risk. 
nsbeta3-/future
Keywords: helpwanted
Whiteboard: [nsbeta3-]
Target Milestone: M21 → Future
Very few users? This bug affects not just our menus, but also all other menus: 
Apple menu, application menu, every fancy-schmancy widget that people have in 
their menus bars, and *are* going to want to get at while a dialog is on screen. 
This is starting to drive me crazy while editing prefs, and wanting to switch to 
a specific other appliction. It's close to dogfood for me.
Keywords: 4xp, polish
I agree with our earlier triage; feel free to escalate this if you don't
Would be a good thing to fix for Mozilla 1.0
Target Milestone: Future → mozilla1.0
*** Bug 42389 has been marked as a duplicate of this bug. ***
*** Bug 55693 has been marked as a duplicate of this bug. ***
*** Bug 49015 has been marked as a duplicate of this bug. ***
Would be an excellent thing to fix for 1.0, as it's apparently causing problems
with switching between certain psuedo-dialogs via the Tasks menu (see Bug 55693
and Bug 49015).
*** Bug 67643 has been marked as a duplicate of this bug. ***
pinkerton: is this the bug you were looking for?
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Nominating nsdogfood since this violates the Mac user interface paradigm
Keywords: nsdogfood
You want this fixed anytime soon, give it to someone else. I'm doomed and don't
want to deal with can of worms this could potentially open.
10 dups. Making mostfreq.
Now, really marking it. Sorry.
BTW I like the "polish" keyword (being a Polish person)
Keywords: mostfreq
*** Bug 85669 has been marked as a duplicate of this bug. ***
*** Bug 101893 has been marked as a duplicate of this bug. ***
pulling into 0.9.7 to decide if we can fix this anytime soon-ish, like for 1.0
Target Milestone: mozilla1.0 → mozilla0.9.7
No longer blocks: patchmaker
*** Bug 69543 has been marked as a duplicate of this bug. ***
*** Bug 64089 has been marked as a duplicate of this bug. ***
*** Bug 111758 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
This bug is very evil, because if the only window on your screen is a dialog 
(like the file download dialog), then you can't do anything; you can't open a new 
window, quit, read mail etc. You have to either force quit the app, or wait ages 
for the download to complete.
Severity: normal → major
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.1
nsbeta1+ per ADT triage team.
Keywords: nsbeta1 → nsbeta1+
Keywords: mozilla1.0+
Target Milestone: mozilla1.1 → mozilla1.0
*** Bug 133161 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 135555 has been marked as a duplicate of this bug. ***
*** Bug 138101 has been marked as a duplicate of this bug. ***
*** Bug 158663 has been marked as a duplicate of this bug. ***
*** Bug 161849 has been marked as a duplicate of this bug. ***
*** Bug 163282 has been marked as a duplicate of this bug. ***
*** Bug 165084 has been marked as a duplicate of this bug. ***
*** Bug 165581 has been marked as a duplicate of this bug. ***
*** Bug 172150 has been marked as a duplicate of this bug. ***
*** Bug 141855 has been marked as a duplicate of this bug. ***
Resetting target milestone. Boy, look at all those dupped bugs! Any chance of
some movement on this one?
Target Milestone: mozilla1.0.1 → ---
*** Bug 143958 has been marked as a duplicate of this bug. ***
Blocks: 4252
*** Bug 85751 has been marked as a duplicate of this bug. ***
*** Bug 133990 has been marked as a duplicate of this bug. ***
*** Bug 147116 has been marked as a duplicate of this bug. ***
Am I missing something?

If this doesn't affect Mac OS X-->mark invalid, and make a note using DOM that
when somebody selects OS 9, say "not supported".

If this does affect OS X-->gradually, stop using modal dialogs, I think they
confuse users, and cause problems like this.
It would require some reworking. Can somebody provide me with a reference so I
can understand what the different options are?

For the record, when I used Macs, there were some dialog boxes, where if you
clicked on the desktop, it would beep.. 
Looking through the dupes of this bug ( OS X trunk) I see two different issues here:

(1) The original bug where menus simply don't function properly with "modal"
dialogs like preferences

(2) Fully functional menus, but poor choices of what menu items are available
for each window type (as in the case of bug 133990 and missing/disabled items
when viewing the bookmarks window)

It's my opinion that any case of the latter should be its own bug (and I know a
few are out there), because its clear the menus are functioning leaving the
former to be dealt with in this, very valid, bug.
I don't think there are any real modal dialogs in Mozilla for OSX, at least in
the traditional sense (must be dismissed before anything else in the app can
proceed).

With just the preferences window, your bookmarks don't appear on the bookmarks
menu, but with no browser window the same thing occurs, so that's probably a
seperate bug.

However, when a download progress window is the only window present, none of
Mozilla's menus are functional.  Is this what people are calling a modal dialog?
 Certainly it can be backgrounded when other windows are present.  Are there
other examples of this type of window?

changed: 
  OS: All->Mac OS X
OS: All → MacOS X
Again, this bug is not about menus not appearing as in "our bookmarks don't
appear on the bookmarks menu" that is a different bug... this is about menu
items that do appear, but clicks get "ignored" such as File > New > Navigator
Window when any "modal" dialog is up - including Preferences.

*This* bug is a problem on platforms pre - OS X. Changing OS to earliest known
Apple OS Version (orignally reported on 8.5) as per convention (e.g. its not ALL
cause it doesn't apply to Linux PPC builds - see bug 90823 and others) and leave
it up to the person creating the patch to fix this bug to decide if the fix
would be applicable just OS X other builds.
OS: MacOS X → Mac System 8.5
We know the cause of this issue, which is what this bug addresses. (For the
curious, it's that the XUL for dialogs doesn't contain any menus, so we keep
showing the menubar for the window behind. The root cause is that Mac is the
only platform that has a global menu bar.) Please don't complicate things by
adding a laundry-list of individual symptoms.
OS: Mac System 8.5 → MacOS X
*** Bug 204883 has been marked as a duplicate of this bug. ***
->sfraser is a much better owner for this
Assignee: saari → sfraser
Status: ASSIGNED → NEW
Target Milestone: --- → Future
*** Bug 135342 has been marked as a duplicate of this bug. ***
Summary: Can't use Mac menu bar when a modal dialog is up → Can't use Mac menu bar with a menuless window (or modal dialog) in front
Blocks: 161561
Blocks: 221813
This "bug" resembles a feature request I have for windows. Sometimes links open
pages in windows without menubars, navigationbars, toolbars, etc. These pages
may have links (or fields, etc.) on them, and when I use one, then I have to
look up the "ALT" command for back, etc. 

I'm not a web programmer, but I think javascript...show details...no_header is
one way to open a window without a menu.

It would be nice if there was a way to "install" a menubar in a window that
doesn't have one, or to prevent a window from NOT having a menubar. At worst, it
would mean that I would have to remember one "ALT" command instead of the whole
slew.

The same command could be used on the Mac side to activate the Firebird menu for
the active (or top) window. 

A remotely related issue is the ability to select and copy information displayed
in the status bar and title bar. Often, the compatibility problems I have with
firebird are related to javascript, and the problem javascript is displayed in
the status bar....
...and he didn't even cc: himself on the bug. Assuming he cares, I've sent
javier email describing MozillaZine forums, dom.disable_window_open_feature.*,
and the JavaScript console.
*** Bug 226506 has been marked as a duplicate of this bug. ***
*** Bug 205195 has been marked as a duplicate of this bug. ***
*** Bug 228615 has been marked as a duplicate of this bug. ***
*** Bug 242336 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a?
*** Bug 242515 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a? → blocking1.8a-
Is someone working on this bug?
Unless this bug is fixed, I suggest the solution in bug 249003 to Mozilla Suite
/ (Any othere xul app we provide) too.
*** Bug 209237 has been marked as a duplicate of this bug. ***
*** Bug 132027 has been marked as a duplicate of this bug. ***
*** Bug 87514 has been marked as a duplicate of this bug. ***
*** Bug 132495 has been marked as a duplicate of this bug. ***
*** Bug 186617 has been marked as a duplicate of this bug. ***
Blocks: 79518
*** Bug 267415 has been marked as a duplicate of this bug. ***
*** Bug 268892 has been marked as a duplicate of this bug. ***
This also seems to block you from opening a new browser window until a download
is completed.
*** Bug 273461 has been marked as a duplicate of this bug. ***
*** Bug 244820 has been marked as a duplicate of this bug. ***
*** Bug 278173 has been marked as a duplicate of this bug. ***
This bug is NOT pre-OSX, this is definitely in OSX.  If you start a download,
close all open browser windows except the download manager, all the menus are
disabled except the Apple Menu and the Firefox menu, neither of which allows you
to create a new browser window.  Keyboard shortcuts are also disabled.  Other
menu bar items (ie: battery status, airport status, clock, etc) are not effected.
I'll confirm this.
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.8a1-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Simon, Javier, Bryner, this seems like it's at or near the top of our Mac
problem list. Can any of you help us with this for 1.8/1.1 ?
note, there is already a workaround patch for ff in bug 239218.
QA Contact: jrgmorrison → bugzilla
I did some related cleanup in bug 282200.
moving blocking status to 1.8b2. perhaps we can get by with the fix at bug
239218. If we decide to go with that, we can minus this for 1.1 and 1.8b2.
Flags: blocking1.8b+ → blocking1.8b2+
Keywords: 4xp, helpwanted, mozilla1.0+, nsbeta1+, nsdogfood, polish
Target Milestone: Future → ---
Depends on: 239218
->josh
Assignee: sfraser_bugs → joshmoz
maybe for 1.8b3
Flags: blocking1.8b2+ → blocking1.8b3+
First, let's clarify which approaches aren't acceptable (as a core fix):
 * "Just" fire the menu items from the window they've been added form. This
isn't the desired behavior sice stuff like view-source-menus in the download
manager doesn't make any sense.
 * Neil has suggested to fallback to the hidden window menus. This isn't
acceptable either because some hidden-window disabled <command>s/<menuitem>s
have to be enabled in 'menuless' windows (e.g. Close Window, Minimize Window).

What we do need is a way to specify an Appication Menu which should be used
whenever a window doesn't have its own menubar, this invloves a lot of code
rewrite which isn't acceptable for the final 1.8 beta.

Given that, and that bug 239218 has made this issue nearly invisble in the
Firefox frontend, I don't think we should block gecko1.8/aviary1.1 on this.
Keywords: arch
Blocks: majorbugs
No longer blocks: majorbugs
Flags: blocking1.8b3+
Flags: blocking-aviary1.1+
*** Bug 307618 has been marked as a duplicate of this bug. ***
Finally fixed on the trunk by bug 355138. See comment #97 in this bug regarding the approach.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.