Sean, this is what we talked about. Right now, if you turn on turbo from the installer, you need to restart your computer to get in turbo mode, and even then turbo will continue to be undynamic until the user goes into Advanced prefs and turns it on (again), which sets the pref. I was just thinking that we could set the pref in the app if the user runs with -turbo (i.e. set it the first time they reboot), but this is lame, and means that turbo won't be able to be dynamic until the first restart (and the state of the checkbox in the prefs won't really reflect the state of turbo mode until a restart).

Reassigning to Syd since he worked on this feature for the installer.

This is critical for emojo and for turning on turbo mode by default.

cc'ing todd as a code red stop-ship warning warning alert. turbo is broken as is.

Blake, I'm not clear on what the issue is - selecting the Quick Launch option in the installer sets the -turbo flag on reboot but then the pref is not set? What's the difference - i.e. explain what you mean by "undynamic." What are we losing - the ability to get into Quick Launch mode without a reboot?

Isn't: http://bugzilla.mozilla.org/show_bug.cgi?id=89956 depending on this or the otherway around?

--> me

Todd, the installer just writes a shortcut, which happens to execute with -turbo flag, but running the browser in some other context (e.g., from command line or from the start menu) will not have a -turbo unless it is explicitly provided by the user. So, why is this needed in eMojo? What is stop ship about this? Also, would like to see a clearer design that describes how this all is supposed to work.

With -turbo mode, there are three possibilities when launching the app: 1) Launch visibly - put self into -turbo mode so when the user quits, we stay resident. This should happen when the app is launched from the installer or when we crash and the user chooses app in start menu to get going again. 2) Launch invisibly - this is what happens at boot-time or when somebody does mozilla -turbo from the command line. 3) Don't launch - forward args to the running instance and quit. This happens when user chooses app in start menu and a -turbo instance is already running. Of these, I think that (1) is either not implemented, needs better integration with the installer, or is broken. We are less than clear on how every scenario is suposed to work. I think agreeing on terminology for the 3 (as I see them) launch modes would help. Then iron out the behavior.

Linking this back to the installer and using Conrad's nomenclature, the installer needs to pass in a flag that means -turboVisible and the use of this flag needs to cause the pref to be set. (I made a similar comment in 97338, but forgot the connotation of Visible when I said that.) We should fix this bug by creating the new option that sets turbo and shows the app. Then, we can fix 97338 by having the installer pass that new option in.

The patch for this is in 88844.

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

Peter - Should this one be nsbranch+, since we are targeting turbo for this release?

I believe this is landed, so I am closing

verified on 0.9.4 Mozilla build (2001091303)