March 16 Mac only, optimized build, apprunner 1. Launch apprunner 2. Click close box on browser window • App quits. On Mac app should remain launched even when all windows are closed.

Re-assigned to mcmullen@netscape.com and set target milestone to M4.

You know, I know that Macintosh apps are supposed to linger after the last window closes - but I also know that that is a source of huge confusion to (1) naive users, and (2) users who use a Macintosh part time, visiting from other platforms. I notice that a lot of small apps (such as control panels) do the "quit if no windows" thing, and as a user I like this. Also, I have a shareware program that does this (on purpose) and nobody has ever complained. Most users, when they close all the windows, are really finished with the application. So I guess I'm being heretical. I think we should consider leaving this the way it is. (Ducking in anticipation of multiple missiles). What do you think, Simon and Peter? You both have strong Mac UI opinions, as indeed do I.

Incoming!!!..........just kidding. All my other Mac apps (BBEdit, Clarisworks, Adobe apps, Resedit, etc.) stay open when all their corresponding windows are closed. I am used to his as a user. What if instead of hiding the app via Finder controls I wanted to "hide" my browser by simply closing the browser or mail window? I happen to do this a lot and it would drive me nuts if the app quit on me. In fact I still swear at my Windows box when it quits nav on last window closure. :-)

Yes, this is heresy. Did your app start as a DA? That's the only typical case for this behavior on the Mac. For every version of Nav/Comm so far, you can start the app with no window, so you should be able to get to that state without having the app quit on you. I say two thumbs down (way down!) on leaving this as is.

Hey, Peter, only one thumb per voter! Accepting bug.

Hear hear. Let's behave like a real Mac application, and stay running with no windows. This may have implications for the way that menus work. Cc:ing saari.

Hmph. I'll make one last whimper before submitting. This is one thing where the Macintosh will differ from other platforms, and where it will require work (eg on menus) which is nontrivial to keep it as a "real" Mac application. Only glynn has given a reason why this behavior is beneficial to the user. And I say unto him, if you want to hide your application, why not use the "Hide Netscape Communicator" menu item. Closing all the windows requires one gesture per window plus one more gesture to switch to some other app. And people whom I know socially and who are "real" end-users (think of this as a euphemism) have called me more than once to solve a problem for them, namely that they closed all their Communicator windows but they couldn't find the "Shut Down" menu item. I am advocating what I think is yes, an innovation which violates the Macintosh tradition, but I think it is a bad tradition and, what is more, to respect it will cost work. Remember, I am as much of a Macintosh traditionalist as any of you.

There is a very good reason why quitting when all windows are closed is really bad. Our startup time is not going to be blindingly short. Experienced Mac users, who will expect the app to keep running after they have closed all their windows, will be continually frustrated when the damn thing quits on closing the last window, forcing them to suffer through a tedious startup process.

I sometimes hide the app via the finder menu and sometimes I hide the app by closing all windows because simply by how the OS UI has affected my workflow. It is easier to hit the close box on a window rather than move the mouse over to the far top right of the monitor to hide the app. Yes, you can now tear off and drag the menu out but in prior OS versions you could not, so my habit is primarily to close windows. I also tend not to like to hide apps because I have encountered nasty OS crashes in the past doing so. Here is another argument to keep the app open. I have the app running in a browser window. I say, hey I am done browsing but I want to send a mail, so I close the browser window and go to open a compose window...DOH! cursing ensues..especially if I have a slow min config machine...especially if I am dialing in....

OK, I consider my suggestion roundly defeated. Thanks for all your opinions.

As for menus... It should be fairly easy to have a menubar without a window. Something just has to AddRef() and hold onto the nsIMenuBar pointer. That something hasn't been written yet.

Let us feast, for the prodigal son has returned to us, he was PC, but is now Mac-like again...

>Let us feast, for the prodigal son has returned to us, he was PC, but is >now Mac-like again... OK, buster. Step outside.

Note: before this bug can be fixed, we need to allow the application to run with no windows open. There has to be a menu bar (with "quit" in it, for example) when the app is in this state. Before this can happen, we need to make a nontrivial enhancement to our xp framework. For example, creating an implementation of nsIWebShellWindow that actually has no visible native window associated with it, and making sure this "window" is frontmost when the last visible window goes away. Note the risk here: there will be Macintosh-only bugs because of this special unique thingummy that will probably only exist on the Macintosh platform.

Changed target milestone to M5.

Question for Chris Saari: is it within my power to fix this, or should this bug really be assigned to you?

You are capable of doing this I think... I can help you with it. The last talked about approach is to make an nsWebShellWindow that is invisible and have that be what is running on the Mac when there are no open windows.

Changed target milestone to M7.

Move to M8 for now ...

*** Bug 7122 has been marked as a duplicate of this bug. ***

*** Bug 7681 has been marked as a duplicate of this bug. ***

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

saari.

Targeting M10

*** Bug 9064 has been marked as a duplicate of this bug. ***

Changing to P1 priority, making a dogfood item.

Hyatt, Waterson, if Dan's invisible window is made visible, the app is fine when all the browser windows are closed. If it is actually invisible so we just get the menu bar on mac, RDF crashs with mDocument being null when I try to SetAttribute in the dynamic menu code. Ideas?

I bet that when the XUL "chrome document" is closed, all the menu items that live inside it get "detached" from their document. Oh wow. The more I think about this the more broken I am afraid this is. We have menu content nodes for _each_ browser window that gets created, right? Which one actually owns the menu bar? The top one, right? And are the menus switched on the fly to make sure that the top window's menu is generated from the right content? I think for Mac to work right, we'll need to make a minimal dummy window with just like a File menu. Am I talkiing crazy?

Yes, we have menu content nodes for each window that is created. Whichever window is currently topmost owns whatever is displayed in the menu bar. As you switch windows, you switch menu bars. You're on the right track, we have a hidden window that can be turned on via this comment from danm: "The quick and somewhat SCSI way is to uncomment and #ifdef XP_MAC line 276 of nsAppShellService.cpp, which currently reads // RegisterTopLevelWindow(newWindow) -- Mac only " Once you turn that on, you have an invisible window with a menubar of its own. You can then close all the browser windows on the Mac, and have a menu bar by itself in true mac fashion. The problem is that once you click on one of the menus in this hidden window's menu bar, RDF crashs with mDocument being null in a SetAttribute call during dynamic menu construction.

Where is the crash? What happens if we just fix RDFElementImpl so that it doesn't crash? (e.g., if mDocument == nsnull, don't try to deref it.)

Well, if we did that, I don't think menus would work, would they? It is the call to set the "open" attribute on the node.

saari, i'll take a look at this. I just uncomment that one line, and then close all my browser windows, right?

right

Waterson, you wanted it, you got it!

Okay, so I uncommented the dreaded line, and now I get _no_ main window at startup. Danm or saari, come sit in my cube when you get a chance so we can debug this.

bounce!

I think davidm fixed this problem. He apparently did it without registering the hidden window. Interesting. Gonna have to find out what he did. But anyway, this bug doesn't happen with current builds.

Marking verified