Since the installer has elevated privileges during the install it launches the app with elevated privileges.

taking... if anyone knows of a good solution for this please comment in this bug. thanks

Can we ask the guys you met when you visited their compatibility lab?

This example from MSDN may be worthwhile - http://msdn2.microsoft.com/en-us/library/ms972827.aspx

(In reply to comment #2) > Can we ask the guys you met when you visited their compatibility lab? From what I can tell from searching there is no straightforward solution available as of yet... I'll ping them though I suspect we will have to write a plugin for NSIS. (In reply to comment #3) > This example from MSDN may be worthwhile - > http://msdn2.microsoft.com/en-us/library/ms972827.aspx Though this drops the rights it doesn't fix the symptom. see bug 368872.

Fx will relaunch itself whenever updater/installer run. We could now de-elevate when updating from Fx 2.0.0.1 because firefox.exe itself performs de-elevation.

Comment on attachment 253668 [details] [diff] [review] de-elevate when relaunch So this will also fix bug 368872

Comment on attachment 253668 [details] [diff] [review] de-elevate when relaunch Thank you Masatoshi Kimura... I did some basic testing of essentially the same changes this morning and it does for the most part solve this. After I complete testing I'll review this.

(In reply to comment #5) > Created an attachment (id=253668) [details] > de-elevate when relaunch > > Fx will relaunch itself whenever updater/installer run. > We could now de-elevate when updating from Fx 2.0.0.1 because firefox.exe > itself performs de-elevation. btw: I believe the case where the same version is installed into the same location will still break when using the installer. Also, if the user launches the app with Run as Administrator this will de-elevate them on restart. I believe we will have to live with these two edgecases where we won't do the right thing.

Comment on attachment 253668 [details] [diff] [review] de-elevate when relaunch >Index: toolkit/mozapps/update/src/updater/updater.cpp >=================================================================== >RCS file: /cvsroot/mozilla/toolkit/mozapps/update/src/updater/updater.cpp,v >retrieving revision 1.27 >diff -u -8 -p -r1.27 updater.cpp >--- toolkit/mozapps/update/src/updater/updater.cpp 30 Jan 2007 05:14:49 -0000 1.27 >+++ toolkit/mozapps/update/src/updater/updater.cpp 1 Feb 2007 20:42:32 -0000 >@@ -1017,17 +1017,17 @@ LaunchCallbackApp(const char *workingDir > // Run from the specified working directory (see bug 312360). > chdir(workingDir); > > #if defined(USE_EXECV) > execv(argv[0], argv); > #elif defined(XP_MACOSX) > LaunchChild(argc, argv); > #elif defined(XP_WIN) >- WinLaunchChild(argv[0], argc, argv, -1); >+ WinLaunchChild(argv[0], argc, argv, 0); I'd prefer that this didn't change so the initial launch of firefox.exe is de-elevated though this would only apply to upgrading to versions of the code that included the change. Please resubmit with that change and I will r=me it or provide an explanation as to why this shouldn't be left like that.

Comment on attachment 253722 [details] [diff] [review] patch - updated to comments r=sspitzer

Checked in to trunk

fixed on the branch.

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.

verified fixed on the 1.8 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2) Gecko/2007021917 Firefox/2.0.0.2. Adding keyword.