96936 - Installer checkbox needs to set default turbo pref (or pass info to app to do so)

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Blake Ross]

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

Comment 1

[Sean Su]

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

Comment 2

[Blake Ross]

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

Comment 3

[Blake Ross]

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

Comment 4

[Todd Pringle]

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?

Comment 5

[Henrik Gemal]

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

Comment 6

[Blake Ross]

--> me

Comment 7

[Syd Logan]

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.

Comment 8

[Conrad Carlen (not reading bugmail)]

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.

Comment 9

[selmer (gone)]

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.

Comment 10

[Blake Ross]

The patch for this is in 88844.

Comment 11

[Conrad Carlen (not reading bugmail)]

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

Comment 12

[Jaime Rodriguez, Jr.]

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

Comment 13

[Syd Logan]

I believe this is landed, so I am closing

Comment 14

[Grace Bush]

verified on 0.9.4 Mozilla build (2001091303)