Closed Bug 3840 Opened 26 years ago Closed 25 years ago

[DOGFOOD][PP]App is quit when last visible window is closed

Categories

(Core Graveyard :: Tracking, defect, P1)

Product:
Core Graveyard
Component:
Tracking
Platform:
PowerPC
Mac System 8.5
* Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: glynn, Assigned: danm.moz)

References

Details

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.
Assignee: don → mcmullen
Target Milestone: M4
Re-assigned to mcmullen@netscape.com and set target milestone to M4.
QA Contact: 3853
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.
QA Contact: 4130
QA Contact: 4130
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M4 → M5
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.
Summary: App is quit when last visible window is closed → [PP]App is quit when last visible window is closed
Target Milestone: M5 → M7
Changed target milestone to M7.
Target Milestone: M7 → M8
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.
Assignee: mcmullen → saari
Status: ASSIGNED → NEW
saari.
Target Milestone: M8 → M10
Targeting M10
*** Bug 9064 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: P3 → P1
Summary: [PP]App is quit when last visible window is closed → [DOGFOOD][PP]App is quit when last visible window is closed
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
Assignee: saari → waterson
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
Assignee: waterson → danm
Status: ASSIGNED → NEW
bounce!
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.