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.

I'll take it.

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

verified duplicate