launching firefox -P will pop up profile manager twice

VERIFIED FIXED

Status

()

Toolkit
Startup and Profile System
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: tchung, Assigned: rstrong)

Tracking

Trunk
x86
Windows Vista
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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

11 years ago
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.

Updated

11 years ago
Component: Profile: Manager → Startup and Profile System
Product: Mozilla Application Suite → Firefox
QA Contact: profile-manager → startup
Version: unspecified → Trunk
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

11 years ago
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
Assignee: nobody → benjamin

Comment 4

11 years ago
Created attachment 288006 [details] [diff] [review]
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.
Attachment #288006 - Flags: review?(robert.bugzilla)
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.
(I also have UAC disabled, I'm not sure how that would impact this bug.)
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.
Attachment #288006 - Flags: review?(robert.bugzilla) → review-
I think I'm getting it twice when it checks for extension updates, if that makes any sort of difference.

Updated

10 years ago
Assignee: benjamin → nobody
Bug 437349 (has a patch in progress that is almost done) should fix this bug
using essentially the approach outlined in comment #7
Assignee: nobody → robert.bugzilla
Depends on: 437349
Fwiw I haven't seen this in ages, though I'm still getting it with Sunbird.
Tony, can you still reproduce now that Bug 437349 has landed on the trunk?
(Reporter)

Comment 12

10 years ago
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.
Tony, that would be due to her not checking it with Sunbird on the trunk after bug 437349 landed.

Resolving -> Fixed by bug 437349.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Updated

10 years ago
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.