Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a8pre) Gecko/2007091104 Minefield/3.0a8pre ID:2007091104 When you have several profiles and you use the profile manager to manage this profile and to select your start profile at Minefield startup, this prevents the minefield start when you click on links in external programs (like Thunderbird) or when you type start -> run www.mozilla.com A Firefox Process is started in the Windows Process Manager, but the profile manager does not come up. This also cause the Problem that when you click on the Minefield icon on your desktop or start menu nothing happens. You need to end the Firefox Process first and then you can start Minefield again. Steps to reproduce: 1. Create some Firefox/Minefield Profiles 2. Choose on the Profile Manager and uncheck "don`t ask at startup", so that the profile manager comes up at every start 3. Start Minefield, make sure its the default browser 4. Quit Minefield and ensure its completely closed 5. Click on www.link in a mail or from start -> run www.mozilla.com 6. nothing happen - minefield does not come up 7. click on the minefield icon in the start menu or desktop -> nothing happen 8. check the process manager - there is a firefox.exe process running

See also: bug 366374, bug 295248, bug 370123.

Litmus Triage Team: Tomcat will add the test case in Litmus. (when this bug is fixed)

Profile Manager is an unsupported feature, so this won't block release. That wouldn't stop us from taking a safe patch, though.

I'm going to try to hunt down the regression range on this. I know it regressed awhile back after a DDE-related checkin. FWIW, this makes nightly testing a royal pain since multiple profiles are a way of life in that arena.

From what I can tell, this regressed between the 2007-02-13 and 2007-02-14 Win32 nightlies, however nothing in Bonsai stands out as a culprit in that range. Can anyone else at least confirm the regression range?

Bug 370123 falls in the regression range of this bug, but a local backout didn't seem to fix things, that apparently wasn't it. If anyone else has any ideas, I'm all ears. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-13+5%3A00%3A00&maxdate=2007-02-14+5%3A00%3A00&cvsroot=%2Fcvsroot

OK, when I attached the VS2k5 debugger to the zombie firefox.exe process, it seems to be dying in nsAppShell::ProcessNextNativeEvent. Not really sure where to go from here...

Does not happen on OS X. Seems to be a Win only bug.

See bug 366374 for Mac OS X

Probably the same bug (deadlock during start when clicking a link e.g. in email) but WITH "don't ask at start up" checked. It is 100% reproducible with FF3 beta 4 on windows xpsp2 (clicking BZ link in TB). This is callstack: > ntdll.dll!7c90eb94() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] user32.dll!7e419418() xul.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=1) Line 154 C++ nspr4.dll!PR_IntervalNow() Line 78 C xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x003286a0, int mayWait=1, unsigned int recursionDepth=0) Line 252 + 0x2a bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fb08) Line 501 C++ xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x003286a0, int mayWait=1) Line 227 + 0xd bytes C++ xul.dll!ProcessDDE(nsINativeAppSupport * aNative=0x0031a3c0) Line 553 C++ xul.dll!ShowProfileManager(nsIToolkitProfileService * aProfileSvc=0x00319a00, nsINativeAppSupport * aNative=0x0031a3c0) Line 1720 C++ xul.dll!SelectProfile(nsIProfileLock * * aResult=0x0012fcdc, nsINativeAppSupport * aNative=0x00000000, int * aStartOffline=0x00000000, nsACString_internal * aProfileName=0x0012fe48) + 0x15dbdd bytes C++ xul.dll!XRE_main(int argc=5, char * * argv=0x00318480, const nsXREAppData * aAppData=0x00317240) Line 2875 C++ Hangs on: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/windows/nsAppShell.cpp&rev=3.64&mark=152#152 I would say this is blocking for FF3 release.

The profile manager is not part of our default UI. This bug should not block (and I'm tempted to WONTFIX it because I think the fix will be quite complicated).

I believe the current plan is to address this when we revamp our startup / os integration for support of protected mode (bug 266533) and better integration support in Fx4 (bug 396196).

This does not block the final release of Firefox 3. Patches with solid tests will be considered, please nominate for approval with summary of risk vs. reward.

I also noticed that if "Don't ask at startup" is checked but you start Firefox 3 _from the Profile Manager_, when you click a link from an external program another Firefox process is created, but it alert the user that Firefox is already running. Firefox tries to start another process with the same profile, but this is forbidden. On the contrary the link should be opened by the already running process, if it uses the default profile.

(In reply to comment #16) > I also noticed that if "Don't ask at startup" is checked but you start Firefox > 3 _from the Profile Manager_, when you click a link from an external program > another Firefox process is created, but it alert the user that Firefox is > already running. Firefox tries to start another process with the same profile, > but this is forbidden. I think this is an already reported bug about profile manager - perhaps WONTFIXed, I don't clearly recall There is also the likes of bug 349858 - I've been able to get multiple Thunderbirds processes open myself.

(In reply to comment #17) > There is also the likes of bug 349858 - I've been able to get multiple > Thunderbirds processes open myself. I don't think it's related. Bug 349858 is a real bug, what I reported seems to be simply a desired behaviour, applied not "smartly".

A quick fix is to remove the '-requestPending' part of the command lines used to start Firefox from protocol handlers. Then Firefox always starts correctly, whether or not you have a default profile (and whether or not it was open already). So instead of: "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1" You just have: "C:\Program Files\Mozilla Firefox\firefox.exe" -osint -url "%1" (Look under My Computer -> Tools -> Folder Options -> File Types -> URL:HyperText Transfer Protocol -> Advanced -> Edit, and ditto for HyperText Transfer Protocol with Privacy, etc) Are there any security implications to this (thinking about bug 384384 in particular)? If not could we just get rid of the -requestPending flag?

(In reply to comment #20) > A quick fix is to remove the '-requestPending' I can reproduce this also without '-requestPending', but with '-no-remote'

(In reply to comment #21) > I can reproduce this also without '-requestPending', but with '-no-remote' > I think that's different: If you launch 'firefox -requestPending -osint -url "%1"' firefox.exe opens but hangs. If you launch 'firefox -no-remote -osint -url "%1"' Firefox terminates immediately (which I believe is *correct*, since -osint means it should reject any other parameters except -url and -requestPending, see bug 384384). For example if you launch 'firefox -no-remote -url "%1"' everything works fine... Incidentally it's worth pointing out that if you remove '-requestPending' from the protocol handlers Firefox will prompt that it's not the default browser every time you start it (unless you disable that), and offer to reset them.

Excuse me, I wrong. I was referring to external program calling, as in Bug 432981. I forget I already discussed about it. Probably Bug 432981 was reported as duplicate of this bug incorrectly?

External programs launching Firefox *is* OS Integration. Trying to change command line arguments in the registry to work around this bug will not work. Removing the dde keys will workaround this bug but is not necessary for the vast majority of users and is not possible under several scenarios so it isn't a way we can fix this bug. -no-remote disables OS Integration in the application but the app is not able to remove the dde keys in several scenarios as stated above so it will also fail under several scenarios. The crash as stated in Bug 432981 has been seen as another affect of this bug. As stated in Bug 432981 if you'd like to reopen it, please do so even though I am quite certain they have the same root cause.

Identificatore build: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9) Gecko/2008052906 Firefox/3.0 These bug is still present on Firefox 3 RC2

Updated to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 today. So this Bug wasn't there in 2.0.0.14. (Just checked 2 times with clean installs) The Quickfix > to remove the '-requestPending' won't work for me. If I change HKEY_CLASSES_ROOT/http/shell/open/command from "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1" to "C:\Program Files\Mozilla Firefox\firefox.exe" -osint -url "%1" The Profile Manager WILL show up, but I get an error message when i try to open a Link from the OS (HTTP-Link on Desktop). AND in addition I get a request if i want to make FF my default browser (because the reg-key doesn't match anymore..). If I open a Link from Thunderbird i wont get an error message, but the request to make FF my default browser. So (for me it seems) the "Ask at Startup" Option for the Profile Manager is currently broken. If you UNCHECK the "Don't ask at Startup" you end up getting a FF-Process without window or Errormsgs. The only workaround might be to CHECK "Don't aks at Startup" until this is resolved and use a Link to '"Firefox.exe" -ProfileManager' to start FF. I guess a lot of People (all that use Profiles and Uncheck "Don't Ask at Startup") will be very confused today!

Error says: "..url.." could not be found. Ensure that you typed in the name correctly and retry. Click Start/Search to search for a File. (When i then choose a Profile and FF opens, the Page is opened correctly - but FF asks if i want to make it the standard browser - because regkey was changed)

Andreas, all of what you wrote is known and the cause of this bug is known. There is just no way to fix this simply but it is on the radar to be fixed.

Adding regression flag due to it is a regression from Firefox 2.

Henrik, this bug existed in Firefox 2 and previous though the behavior seen by the user is different.

ProcessDDE will block until 20 messages are retrieved from queue, but no messages will come after system sent DDE messages because no window is visible. So it will wait forever. This patch should fix the problem.

Comment on attachment 325770 [details] [diff] [review] patch Excellent! >diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp >--- a/toolkit/xre/nsAppRunner.cpp >+++ b/toolkit/xre/nsAppRunner.cpp >@@ -525,37 +525,39 @@ CheckArgShell(const char* aArg) > > /** > * Spins up Windows DDE when the app needs to restart or the profile manager > * will be displayed during startup and the app has been launched by the Windows > * shell to open an url. This prevents Windows from displaying an error message > * due to the DDE message not being acknowledged. > */ Could you please update the comment to reflect the aWait param? Perhaps something like /** * Enabled Native App Support to process DDE messages when the app needs to * restart and the app has been launched by the Windows shell to open an url. * When aWait is false this will process the DDE events manually. This prevents * Windows from displaying an error message due to the DDE message not being * acknowledged. */ r=me with that.

This bug occurs on Linux?

(In reply to comment #35) > This bug occurs on Linux? No, this bug is specifically for Windows though there is a similar Mac OS X bug and I wouldn't be surprised if there was a similar Linux bug.

Carrying over r+ per comment #34. Robert, would you check in the patch?

I'll check in the patch in the next day or two unless someone else beats me to it.

Checked in to mozilla-central changeset: 15466:fea2ed527946 tag: tip user: Robert Strong (robert.bugzilla@gmail.com) date: Fri Jun 20 17:21:21 2008 -0700 summary: Bug 395891 - Profile Manager prevents Minefield startup from OS Integration points (links in Mails, etc). patch=Masatoshi Kimura (:emk) r=rob_strong

Verified. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062103 Minefield/3.1a1pre Nominating for 1.9.0.1.

Comment on attachment 325942 [details] [diff] [review] comment updated This patch applies to 1.9 branch cleanly. This will fix a hang-up bug left on the branch. It affcts only "unsupported" code path, so the risk is minimal.

There's still a little problem. If Firefox starts with -profilemanager -no-remote, when you click a link from another program or you open a page in local, Firefox profile manager starts. If you select a profile already in use, Fx returns error. I think the correct behaviour should be: profile manager must open the link in a new tab of a window of the profile in use. Must I open another bug for this problem?

(In reply to comment #43) I think it's an expected behavior. -no-remote means "I won't accept DDE messages". And you cannot share a profile among multiple Fx instances. Anyway, please file another bug.

Done: Bug 441035. PS: it's not very important any more, but this bug was not a regression, as written in Comment 6?

Lucas, read comment #30

(In reply to comment #46) > Lucas, read comment #30 > Hi Rob. I've read this comment, and in fact all the other comments. However, I haven't found an explanation as to why the behaviour is different. The behaviour I'm experiencing myself with the current Fx 3 release seems to match comment #0. With Firefox 2, I was able to open links "normally". That is, if no Firefox process was running, clicking a link somewhere showed the profile manager, and I would select the profile I wanted, and the link would open (in addition to session restore etc.) So, from my user experience point of view, this is a regression. I'm not sure if the described behaviour on Firefox 2 is what you meant in terms of "different" behaviour, with the same bug present in the backend. Either way, while there may have been a more subtle bug in the Firefox 2 behaviour (which I apparently have missed all those years, and haven't seen you expand on, though apologies if I missed the relevant bits), from my perspective this seems like a regression. Could you explain how you think it is not a regression, and/or how my experience with Firefox 2 was different from what you would have expected? Thanks!

Hi Gijs, this bug primary cause is restarting during startup which we do when launching the profile manager. In 1.0 thru 1.5 there was a hack that worked with users that had admin right but no others that removed / added the DDE integration and conversely affected users that weren't running as admin... the hack was removed with 2.0.0.2. So, the bug existed as early as 1.0 though it had a hacky workaround that didn't fix all cases and the exact behavior did change periodically as other code changed. I won't claim that I am positive that it isn't a regression but from what I know from following this issue since 1.0 and working on incremental fixes this isn't a regression though the affected user base did change at times. Other code changes may have also caused changes as far as what the user experienced. Also, I a change in the code base hasn't been identified as the cause besides the removal of the hack that only fixed this for users with admin rights.

I'm also seeing the same symptoms as reported in comment #0 (see also the duplicate bug 443772). I understand this bug was recently marked "fixed." Forgive my ignorance with Bugzilla, but in what version was this fixed? (And where can I get it to test/try out... I have virtual several different machines I can dedicate to testing this issue.)

It's fixed for Firefox 3.1. You can download any nightly build newer than June 21 with the fixed code from the link below or you can wait for alpha 1 of Firefox 3.1 to be released later this summer. ftp://ftp.mozilla.org/pub/firefox/nightly/

Oops, I should have noted that if you want to try a nightly with the fixed code, use one of the mozilla-central builds.

Comment on attachment 325942 [details] [diff] [review] comment updated Can we get a test for this patch before approving?

Samuel, this code runs extremely early during startup where we have little to no test coverage due to the issues with testing code this early on. This also only changes the profile manager code path which is technically not supported though it has not been removed as of yet if it ever will be. It also invloves Windows DDE which doesn't work reliably if at all on debug builds due to how much longer it takes a debug build to launch which once again would make it damn near impossible to run the test in a debug environment. So, I highly doubt we will get a test for this at any point soon if at all.

I have tested this patch with the latest nightly build in a virgin WinXP environment and can confirm that it does indeed resolve the problem described. Not very scientific, I know, but it's the best I can do.

Comment on attachment 325942 [details] [diff] [review] comment updated Rob, thanks for the reply. We definitely need a Litmus testcase for this, in that case. Tomcat, can you cover that? Approved for 1.9.0.2. Please land in CVS. a=ss

Kimura-san, would you like me to land this for 1.9.0.2?

(In reply to comment #59) > Kimura-san, would you like me to land this for 1.9.0.2? Yes, please.

Check in for 1.9.0.2 / Firefox 3.0.2 Checking in mozilla/toolkit/xre/nsAppRunner.cpp; /cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v <-- nsAppRunner.cpp new revision: 1.213; previous revision: 1.212 done

Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) Gecko/2008080305 GranParadiso/3.0.2pre ID:2008080305 I tried to open several URLs from inside Thunderbird, IM client, and Start|Run. The profile manager is now shown and Firefox starts fine.

Litmus testcase added: https://litmus.mozilla.org/show_test.cgi?id=5890

i use firefox 3.0.05 and it doenst work for me