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.
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.
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.
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
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.
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?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199pre) 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
You need to log in before you can comment on or make changes to this bug.