Reproduction: 1. Use WindowWatcher to open and close a window during startup (in profile code in my case) 2. Start Firebird, close the custom window that comes up during startup Actual result: Firebird executable exits quickly after the custom window closed Expected result: The Firebird main window comes up. This works for Seamonkey, there, the navigator window comes up as expected. Additional Comments: I hit this with roaming (bug 124029), makes it unsuable with Firebird. I suspect that something is confusing my window with the main window, nsAppShellService::Ensure1Window() or something in that area?

Ben, I'm not sure what to make of this bug report. Are you asking for debugging help? My guess is that you're running afoul of the assumption the app makes that it should quit when the last window is closed. If that's correct your new window code must be located next to, not within the profile code because the profile code takes special steps to circumvent that assumption. See for example nsAppShellService::DoProfileStartup. That's a short method. You'll see it. Be careful. The last window closing dance is still a little delicate and keep the Mac in mind, which behaves differently. Assuming I've understood correctly, I'm closing this bug.

> Are you asking for debugging help? No, I am running into a problem with Firebird which doesn't exist with Seamonkey, Seamonkey behaves as expected, Firebird doesn't. I thus assume that it's a bug in Firebird, not my code. > My guess is that you're running afoul of the assumption the app makes that > it should quit when the last window is closed Yes, actually, it quits after the *first* window (actually a dialog) closed. I think that's a bad assumption, because there are many cases thinkable where code might have to ask the user questions during startup (before the main window came up). And Seamonkey can live without that assumption, although I don't know how that is implemented. > If that's correct your new window > code must be located next to, not within the profile code I'm not sure what exactly you are suggesting. My code is one of the (middle) steps needed to startup and shutdown a profile. > See for example nsAppShellService::DoProfileStartup. Are you suggesting that I hack special code for roaming into the appshell?

BTW: It shouldn't *quit* either after the last window closed, but it should shut down. My code also needs to show dialogs during shutdown.

OK, the Firebird-specific nature is surprising. So maybe something's going on that I don't get. I'm saying only that by design the app does quit as soon as you close the last XULWindow (of course last is first if first is only :)). Firebird and Mozilla should both behave the same. I'm also saying there's a way to override that behaviour. I don't know how appropriate it is for your situation. If you've found a genuine basic problem then by all means reopen the bug. But I'm afraid it's you who gets to fix it since only you can replicate it. Some funky stuff happens during shutdown/quit, too. It's designed to abort if another window pops up at the last moment, as in an unload handler. It might work for you as is but you're probably exercising it in new ways.

> So maybe something's going on that I don't get. Given that my code is invoked from the profile code, maybe my code happens to take advantage of the special case hacks for the profile selection dialog that you pointed me to? I'm only guessing here. Maybe nobody noticed this bug with Firebird, because Firebird doesn't use profile selection? > I'm afraid it's you who gets to fix it since only you can replicate it I'm afraid that I have neither the competence to fix it nor the time to find it out. > Some funky stuff happens during shutdown/quit, too. It's designed to abort > if another window pops up at the last moment, as in an unload handler. > It might work for you as is but you're probably exercising it in new ways. Yes, it does happen to work for me, luckily, at least in Seamonkey.

> by design the app does quit as soon as you close the last XULWindow > (of course last is first if first is only :)). It depends on when you start to look for the "last" window. You shouldn't even consider to quit until the main window came up (or something else explicitly told you to close down). By the design you describe, you are taking an arbitary window, that happens to come up, as the main window, and I think that's wrong.

If this is Firebird specific, it should be in the Phoenix product.

.

I just stumbled across EnterLastWindowClosingSurvivalArea(); ExitLastWindowClosingSurvivalArea(); Maybe that's what I need to do?

> See for example nsAppShellService::DoProfileStartup. Yeah, it was exactly in that function. Maybe I should have opened my eyes more. > That's a short method. You'll see it. Obviously, I didn't :(. I'm still not totally getting what you meant with "your new window code must be located next to, not within the profile code" in comment 1, because my code needs to open a window just like profile code may (profile selector), so my code and profile code has the same needs, not? I guess I'd have to investigate this all further, checking, which code paths firefox goes and which ones seamonkey goes. (I love Firefox's forks.) I currently don't care enough. Anyways, closing this as INVALID until I know more.

>located next to, not within the profile code I think I was just surmising that your code must be closing a window at a time not already protected from premature exit by the profile code. Not important. The EnterLastWindowClosingSurvivalArea part you've noticed was the useful part.