Closed
Bug 364483
Opened 18 years ago
Closed 18 years ago
Firefox stays elevated after update
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 367540
People
(Reporter: emk, Assigned: robert.strong.bugs)
References
Details
(Keywords: verified1.8.1.2, Whiteboard: [vista])
I have updated Firefox 2.0 to 2.0.0.1.
After update, Fx started automatically with elevated privilege.
Some users may continue to browse using elevated Fx. (thanks to the session restore!)
Updater should be "un-elevated" before launching Fx.
Updated•18 years ago
|
Flags: blocking1.8.1.2?
Comment 1•18 years ago
|
||
We need some one to take a look at this ASAP... rstrong or sspitzer perhaps? We need this for 2.0.0.2.
Flags: blocking1.8.1.2? → blocking1.8.1.2+
Reporter | ||
Comment 2•18 years ago
|
||
My patch attached to bug 351949 also fix this.
Rstrong, Please hurry up review.
Updated•18 years ago
|
Assignee: nobody → VYV03354
Reporter | ||
Comment 3•18 years ago
|
||
Sorry, I have no enough time to make a new patch, test, request review, ask for approval until code freeze.
Anyway, my patch didn't work when updating from 2.0.0.1 (or earlier) because old updater has no ability to "un-elevate". Firefox.exe should relaunch itself to drop the elevated priv after post-update.
Reassigning to rstrong because bug 351949 is also reassigned.
Assignee: VYV03354 → robert.bugzilla
Comment 4•18 years ago
|
||
robert tells me that bug #351949 contains the fix for this.
thanks again to
QA Contact: software.update → robert.bugzilla
Comment 5•18 years ago
|
||
> thanks again to
thanks again to Masatoshi Kimura for working on our Vista support!
Assignee | ||
Comment 6•18 years ago
|
||
note: this is not fixed for 1.8.1.2 but will be for 1.8.1.3 by the patch that landed in bug #351949. I will look into what we might be able to do for 1.8.1.2 as time permits
Assignee | ||
Comment 7•18 years ago
|
||
Resolving as duplicate of bug 367540 since that is where the patch is
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Updated•18 years ago
|
Whiteboard: [vista]
Assignee | ||
Updated•18 years ago
|
Assignee | ||
Comment 9•18 years ago
|
||
To verify this you must get the UAC dialog (e.g. allow / cancel) and not the runas dialog. When launching the app you should not be able to save a web page in the root of the c: drive.
note: with trunk it wasn't possible to save to the root of the c: drive since the trunk didn't have the shim to elevate the updater.exe
Comment 10•18 years ago
|
||
verified on the 1.8 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2pre) Gecko/2007021503 BonEcho/2.0.0.2pre. Verified using rstrong Comment 9 - I get the allow/cancel dialog (albeit twice), and I am **unable** to save a file to the root C drive - trying to do save generates an error dialog notifying me I don't have permission to save in this location.
Thanks to rstrong for always providing good steps to verify - this is something that is greatly appreciated by QA, especially me since I am making the transition from primarily testing Mac to testing Windows and still learning many of the ins and outs of Windows.
Keywords: fixed1.8.1.2 → verified1.8.1.2
Comment 11•18 years ago
|
||
verified on the 1.8 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2pre) Gecko/2007021503 BonEcho/2.0.0.2pre. Verified using rstrong Comment 9 - I get the allow/cancel dialog (albeit twice), and I am **unable** to save a file to the root C drive - trying to do save generates an error dialog notifying me I don't have permission to save in this location.
Thanks to rstrong for always providing good steps to verify - this is something that is greatly appreciated by QA, especially me since I am making the transition from primarily testing Mac to testing Windows and still learning many of the ins and outs of Windows.
Updated•16 years ago
|
Product: Firefox → Toolkit
Assignee | ||
Updated•6 years ago
|
QA Contact: robert.strong.bugs
You need to log in
before you can comment on or make changes to this bug.
Description
•