186617 - windows without menus (like message search dialog) have problems on mac os

Status: RESOLVED DUPLICATE of bug 21296

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

something that sfraser found (and fixed, for the download manager, see bug #155426)

any of our windows that don't have menus (that aren't modal dialogs) can lead
mac  users into a weird state.

mac has the menu at the top.  so if our current window doesn't have a menubar,
and we close all other windows, the user is left in a state where they can't
(intuitively) get back to the app.  the menu will be there on mac, but will be
horked.

sfraser's solution for the download manager was to have a mac specific overlay,
that flushes out the menubar for mac only.  (you could argue that on win/linux,
getting into the state where you had a window up, with no menu bar, you are in a
similar state, but I don't know the UI standard for those platforms for this
scenario.)

is the solution to add a menubar to our top level windows?  is the solution to
do what sfraser did, for mac only?

Comment 1

[jglick]

For Mac, even when you close all the apps windows and dialogs, the app is still 
running until you actually Quit the app. So on Mac, if the app is still running, 
whether that be only a non-modal dialog visible, or no windows/dialogs visible, 
the user should be able to access basic funtionality, such as "New 
Browser/Message/AB Card" etc. Menu items specific to a particular window would 
not be enabled though(such as Send Page).

Windows is different. Once all windows/dialogs related to an app are closed, the 
app quits. I just tried this with MS Word: had a doc open, opened a non-modal 
dialog, closed the main doc. Results: the app quit and the non-modal dialog 
disappeared. Maybe this is what we want to follow for Windows. Once the last 
main window has been closed (a window with a menu bar), the app quits and any 
non-modal dialogs close as well.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I suspect that the behavior jglick saw is just caused by the dialog being 
parented to the main doc (to test, open two main docs, open the dialog from one 
of the main docs, then close that main doc and see whether the dialog closes 
too).

Comment 3

[Frankie]

Possibly another dupe of bug 21296 (although the summary should probably be
changed).

All of these stem from the same root cause -- the Mac menu bar "thinks
different" from (X or MS) Windows, and Mozilla's various subsidiary windows
(dialogs, managers, etc) don't work the way MacOS expects.

Comment 4

[Frankie]

*** This bug has been marked as a duplicate of 21296 ***