Closed Bug 97338 Opened 20 years ago Closed 20 years ago

Checking box for Quick Launch in Installer does not start Mozilla in turbo mode

Categories

(SeaMonkey :: General, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 96936
mozilla0.9.4

People

(Reporter: agracebush, Assigned: ccarlen)

References

Details

Attachments

(1 file)

This can be reproduced with setup of 0,1,>1 4.x migrated profile- with either 
Mozilla or N6.1
Steps to reproduce:
1. Clean system (remove old profiles)
2. Run Installer and check box for Quick Launch

expected result:  Mozilla/N6.1 will run in turbo mode (icon will display in 
systray)

actual result: app launches with profile
in profile if I check prefs/advanced/turn turbo on and icon gets placed and tray
 
do not have to reboot (see bug 91350)
cc: blake
A couple things:

First, Conrad, I think the problem Todd was having was a little different than
you described; even when I converted over to an nsIRegistry-based scheme and
moved the check to before the profile mgr init'ing, the profile manager still
wasn't showing UI.  I think the problem is that the profile manager isn't
currently aware of the concept of starting in turbo, but still wanting to show
UI, i.e. it shouldn't show UI for -turbo (mozilla-on-startup), but it should for
just starting up mozilla in turbo mode.  If I keep the check after the profile
mgr init'ing, the profile manager properly doesn't show until double clicking on
the icon when running -turbo, but does show when just running normally in turbo
mode (but you're not actually in turbo mode until after choosing your profile).
 I'm sure there's a problem there that I'm not considering.

Second, I think that instead of using some turbo-is-enabled key, or a pref-based
scheme, or anything else, we should just change our method of starting Mozilla
on startup to adding ourselves to the Run key of the registry (which, from what
I read, is what we should be doing anyways), and then check the existence of
*that* as an indication of turbo mode.

This would mean finally unifying the two concepts of turbo: starting Mozilla on
startup and hiding it (to speed up first run), and keeping Mozilla open after
you close it (to speed up subsequent runs).  I'll be the first to admit that
QuickLaunch isn't the best name for these features, and, also, that trying to
merge these two concepts is what's causing (I think) lots of heartache in the
backend.  Some apps distinguish between the two.  I notice that AIM, for
example, has a start-when-Windows-starts feature feature that can be changed by
the user, but a minimize-to-system-tray behavior (complete with a `we're in the
sys tray' alert just like ours) that seemingly can't (I think that once used to
be a pref, though).  Note that one difference between them and us is that they
have a Sign Off... menuitem which will sign off, and then the user can close the
Sign On screen; the only way to close us is from the system tray icon.

So, in short, we need some input here from UI folks and others.
some one want to take this from me before I randomly reassign it.
Browser-General is for people who don't know how to file bugs.
> I think the problem is that the profile manager isn't currently aware of the
> concept of starting in turbo

While it doesn't know exlicitly about -turbo mode, it is told whether it is
allowed to show UI. What happens is this:

(1) The app is launched with the -turbo arg. In this case, the profile mgr is
told that it can't show UI. If it needs to and can't, it returns
NS_ERROR_PROFILE_REQUIRES_INTERACTION. On this error,
nsINativeAppSupport::SetNeedsProfileUI(PR_TRUE) is set.
(2) The app is lauched again, without the -turbo arg.
nsNativeAppSupportWin::EnsureProfile() calls GetNeedsProfileUI() and, if TRUE,
calls the profile mgr, telling it that it can show UI.

If we're depending on a pref to determine whether we're in -turbo mode and that
check doesn't happen until after profile mgr has been inited, profile mgr will
be allowed to show UI, the call to nsIProfileInternal::StartupWithArgs() in (1)
won't fail, so nsINativeAppSupport::SetNeedsProfileUI() won't be called. Then
each pass through (2) won't show UI.

I think the needsProfileUI attr on nsINativeAppSupport is unnescesary and is
causing trouble. At this point:
http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp#1483
simply calling DoProfileStartup will do the right thing: If there is one
profile, it will be set without showing UI and if there are multiple profiles,
profile UI will be shown.
need new owner for this bug.  reassign to conrad.  If this belongs to blake or 
someone else, pls reassign.

We may want this one for nsbranch.
Assignee: asa → ccarlen
Keywords: nsbranch
QA Contact: doronr → gbush
I'll take it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Conrad,
see also bug 96936- duplicate?
This is a feature request, not a bug. The checkbox in installer is only designed
to write a shortcut in the startup folder, and requires a reboot.

Just so everyone knows what is going on here.
Syd,
Agree, it is hard to know what is supposed to work with this feature.  See bug 
93150- now you are NOT supposed to reboot- in fact, if you change the pref, the 
icon displays immediately in systray.  

Do you have 'spec' for this? It is becoming a circular set of bugs!
thanks,

Spec! Hahahahahahaha :-)

Maybe Blake Ross has one, as he seems to have written the most bug comments so
far on this? If not, can someone publish a spec for us to look at and provide a
link? We prolly should have buy off from Todd on this spec before we start doing
the work.
Does any one else think its too lte for feature definition for this milestone?
Propose we move it out to a later milestone.
It seems like the trivial solution here is to pass the -turbo flag in when the
installer first launches the app.  Doesn't that either solve this or
sufficiently cover the hole until we can find some bigger better thing to do?
-turbo currently suppresses UI, so we'd have to add code to turn the server mode
on but ignore the UI suppression if the -installer flag (or maybe just any other
args) were used.
See also bug 96936 :-)

*** This bug has been marked as a duplicate of 96936 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Blocks: 99194
verified duplicate
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.