I've previously set up N6.1/mozilla to start both browser and mail/news in the main profile I use in a multi-profile setup. I installed 2001 09 1003/0.9.4 build on win98 and took the default to have turbo mode start.. when I start up now only the browser launches. If I shut down the browser kill off the turbo mode instance and then click on the desktop icon, the both browser and mail news starts...

Try a trunk nightly.

can we resolve this?

...0.9.4 branch build from today Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010917 Netscape6/6.2 does not honor the pref for me...

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

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

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

The pref is honored when you're starting Mozilla when not already in turbo (i.e. if you right click the systray icon, exit, and then start Mozilla). The fact that it doesn't work when you're already in turbo mode really isn't much of a turbo bug; the code path is the same as that followed when you double click the Mozilla icon with a window already open (it just opens a Navigator window, which I guess really isn't correct).

Right; "turbo mode" just puts us in a state where the prior logic doesn't always have the desired result. I can think of two reasonable fixes: a. Treat the *first* request that comes in to a running turbo-mode Mozilla differently from subsequent requests and do the check-prefs+open-all-windows thing. b. Treat *all* requests that come in while there are no open windows this way.

Seems related to my bug - 107966 - Startup always goes to Browser even if set to go to mail

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

->mozilla0.9.7/p2, this has to work seamlessly in turbo mode.

Mass moving bugs that won't get fixed this milestone.

balancing move of Helper App Mgt feature work bugs to this milestone

So what do UI folks think about the option Bill presented in comment #8: a or b?

My take on this is that QuickLaunch is nearly invisible to the user, or should be, as it is in IE. If we have no windows open, and they launch us, we should open the components they've specified in their prefs. Why would the number of times they've launched make any difference? I'd like to hear from Marlon & MPT though. BTW, Bill- this bug is important, which is why I targetted it for 0.9.7. It can't slip two more milestones, let alone three. If you won't be able to get to it in 0.9.7 or early 0.9.8 at the latest, then we need to reassign it. ->0.9.8

This is sorta ugly, and it seems like it should adversely affect DDE when you're in turbo (although cursory testing didn't reveal anything)

Bill, could you comment on this?

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

related to bug 58523?

1. re: Converting mServerMode and other member data fields from regular members to static members I don't think that is necessary. While it works in this case because the object in question is a service, I don't think convention is to do it this way (i.e., other components/services don't). To solve the problem of accessing the members from startupPrefEnumerationFunc, you can pass a pointer to some sort of "closure" object (that holds a pointer to the nsNativeAppSupportWin object, along with a pointer to the prefs object). See the similar code in nsAppRunner.cpp. 2. re: startupPrefEnumerationFunc It would be nice if we could simply reuse the code in nsAppRunner.cpp. It would be relatively easy to export the function from there and import it here. I don't know if that code can be used as-is, but it might be easier to tweak that than to have two separate copies of the same code. 3. re: making sure at least one window opens What happens if none of general.startup.* are true? There doesn't seem to be any failsafe mechanism to ensure a browser window opens (the equivalent of Ensure1Window in nsAppRunner.cpp). 4. re: Check for open windows? Shouldn't this logic only kick in if there are no windows? 5. re: DDE There shouldn't be an ill-effects here. The DDE code explicitly opens a browser window by calling HandleRequest with "-url" so it goes to OpenBrowserWindow.

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

To fix bug 88123, I had need of re-using even more of the code from nsAppRunner.cpp so I coded up the patch that exposes that code and calls it from nsNativeAppSupportWin. That patch also fixes this bug. I'm looking for a r/sr for that patch.

I believe the more complete patch has now been checked in.

Verified Fixed win XP build 2002030703