386379 - launching firefox -P will pop up profile manager twice

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Tony Chung [:tchung]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6

When i create a new profile using profile manager, it opens up the dialog twice.  This is done from the command line, and on vista only it seems.   

Not reproducing on minefield, only trunk builds.

Reproducible: Always

Steps to Reproduce:
1. Install trunk build on vista, admin mode (Alpha6_r2)
2. open command window, and launch firefox profile manager. "firefox.exe -P"
3. watch profile manager open.  create a new profile, and click "Start minefield"
4. Verify the dialog dissapears, the timing icon shows up, and the profile manager window pops up a second time.

* Selecting the profile the 2nd time will really start minefield.
Actual Results:  
profile manager dialog appears twice when trying to start.

Expected Results:  
profile manager dialog should only appear once, and launch firefox afterwards.

Comment 1

[cmtalbert]

I can confirm this behavior on Vista with alpha6RC2.  Also, I think there is a nasty little side-effect of this bug for non-administrative users.

1. Load Alpha5 on Vista.
2. Set up the profile manager to always display when Firefox starts
3. Install Alpha6_rc2
4. Attempt to run Firefox using a non-administrative user by clicking on the GP icon on the desktop.  
5. Note that the process will load, but you will see neither a profile manager or the main application UI.
6. Take the profile in question to the administrative account
7. Start GP using this profile on the administrator account. 
8. You get the double display of the profile manager that tchung describes above.

Comment 2

[Majken Connor [:Kensie]]

I get the same issue both with -p and also from unchecking "don't show at start up"

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre

Been getting it since I switched to trunk, which was in July, I believe.

Comment 3

[Benjamin Smedberg]

This is another manifestation of the root bug in bug 386826, but the solution there won't solve this problem. I'm going to put up a patch for the solution I mentioned in bug 386826 comment 16

Comment 4

[Benjamin Smedberg]

Attachment: Pass an explicit environment block, rev. 1

I'm going to send this to the tryserver and get someone to test on Vista, which I don't have.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This patch doesn't fix the problem described in comment 0 for me, using Tony's steps to reproduce on Vista. I've been seeing a similar issue when restarting for software updates, but I can't seem to be able to reproduce it now, so I don't know whether the patch affects it.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(I also have UAC disabled, I'm not sure how that would impact this bug.)

Comment 7

[Robert Strong (they/them - no direct email)]

Comment on attachment 288006 [details] [diff] [review]
Pass an explicit environment block, rev. 1

The root problem here is we relaunch using the desktop's token in order to de-elevate after a software update.

From reading other people's attempts at solving the elevate / de-elevate problem the only decent way to get around this is to use a stub launched from Firefox without requesting elevation, etc. that then launches the updater.exe requesting elevation and then launches Firefox.

Comment 8

[Majken Connor [:Kensie]]

I think I'm getting it twice when it checks for extension updates, if that makes any sort of difference.

Comment 9

[Robert Strong (they/them - no direct email)]

Bug 437349 (has a patch in progress that is almost done) should fix this bug
using essentially the approach outlined in comment #7

Comment 10

[Majken Connor [:Kensie]]

Fwiw I haven't seen this in ages, though I'm still getting it with Sunbird.

Comment 11

[Robert Strong (they/them - no direct email)]

Tony, can you still reproduce now that Bug 437349 has landed on the trunk?

Comment 12

[Tony Chung [:tchung]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1pre) Gecko/2008062406 GranParadiso/3.0.1pre. 

No Repro anymore, but i'll leave this bug as new since lucy still sees this in comment 10.

Comment 13

[Robert Strong (they/them - no direct email)]

Tony, that would be due to her not checking it with Sunbird on the trunk after bug 437349 landed.

Resolving -> Fixed by bug 437349.