99321 - turbo mode does not honor pref to start mail-news and browser at launch time

Status: VERIFIED FIXED

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect, P2)

Description

[chris hofmann]

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...

Comment 1

[Blake Ross]

Try a trunk nightly.

Comment 2

[Peter Trudelle]

can we resolve this?

Comment 3

[chris hofmann]

...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...

Comment 4

[Jesse Ruderman]

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

Comment 5

[R.K.Aa.]

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

Comment 6

[Alfonso Martinez]

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

Comment 7

[Blake Ross]

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).

Comment 8

[Bill Law]

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.

Comment 9

[hanasaki]

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

Comment 10

[timeless]

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

Comment 11

[Peter Trudelle]

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

Comment 12

[Bill Law]

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

Comment 13

[Bill Law]

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

Comment 14

[Blake Ross]

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

Comment 15

[Peter Trudelle]

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

Comment 16

[Blake Ross]

Attachment: patch v1

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)

Comment 17

[Blake Ross]

Bill, could you comment on this?

Comment 18

[Blake Ross]

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

Comment 19

[R.K.Aa.]

related to bug 58523?

Comment 20

[Bill Law]

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.

Comment 21

[Dimitrios]

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

Comment 22

[Bill Law]

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.

Comment 23

[Blake Ross]

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

Comment 24

[Terri Preston]

Verified Fixed win XP build 2002030703