User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20060907 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20060907 Minefield/3.0a1 When I use firefox or if I just want to update my nightly build it first downloads and installs the new nightly patch, but then it wants to install a new patch I let it install and it restarts and then wants to install the last patch again and does this forever. Reproducible: Always Steps to Reproduce: 1.update nightly build on Vista RC1 2.restart browser to install patch 3.press check for updates and install new patch 4.press check for updates and install new patch and restart. Actual Results: it keeps on wanting to update the same patch over and over Expected Results: It should have realized there was nothing to update.

(In reply to comment #0) This might be a bug I reported to MS. If Firefox is installed in the Program Files directory then the user will need administrator rights in order to update. No LUA prompt is given and so the update silently fails. Was the browser really updated in your case?

I believe this was just a problem with a certain nightly build it seems to no longer occur with the recent nightly builds.

I experienced this when going from 2.0b1 to 2.0b2. Even if a change was made to the update code this may very well still be a problem when going from 1.5.0.x to 2.0 since the updater.exe that performs the update will be from 1.5.0.x.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061110 Minefield/3.0a1 ID:2006111004 [cairo] This is still happening for me. Update downloads the full version. I click restart and the browser restarts without updating. This happens on 2 different boxes. One with RC1 and one with RC2. In fact, the only way I can currently update is to download the zip. If I run the installer, the update horks my flock install. (I should check for the bug on this)

For completeness, could someone attach <firefox dir>\updates\last-update.log from one of these failures. Please make sure the file modification time corresponds to the failed attempt.

You need to run Firefox as administrator (Right click on the shortcut and select "Run as administrator"). This allows the Firefox executable to write to its directory in the program folder....which it needs to do to update. I believe this was in another bug (or maybe it was only a forum post)

I believe I was experiencing this on Vista RTM until I disabled UAC (User Account Control). Now that UAC is disabled, the update works fine.

confirmed! this is my problem since i upgraded to vista.

appropriate title for this bug is "Automatic Update is not working for vista users with limited account privilege"

(In reply to comment #9) > appropriate title for this bug is "Automatic Update is not working for vista > users with limited account privilege" > and UAC enabled"

automatic update system (AUS) from trunk build 2006121904 to build 2006122004 is NOT WORKING. but from build 2006121804 to build 2006122004 is WORKING fine. same setting with limited account privilege and UAC (User Account Control) enabled

(In reply to comment #11) > automatic update system (AUS) from trunk build 2006121904 to build 2006122004 > is NOT WORKING. > > but from build 2006121804 to build 2006122004 is WORKING fine. > > same setting with limited account privilege and UAC (User Account Control) > enabled I'm confused - it seems this bug is about update not working when UAC applies. If it is in fact working, and has regressed then that should be a new bug. I don't know if the version bump from 3.0a1 to 3.0a2pre is relevent, but it occurred between the nightlies of the 18th and 19th.

maybe it had something to do with bug# 364628

(In reply to comment #13) > maybe it had something to do with bug# 364628 Actually bug 364477. Since that's not fixed yet (waiting on bug 364625 to push the change to the live server) none of the Firefox trunk builds from 20061219 are update-able. You really shouldn't have piggy backed onto this bug. The symptoms don't match - you would have seen "No updates found", rather than the update not applying after download. You're effectively trying to morph this bug, which rapidly makes it much less useful by filling it with noise.

Indeed. The 2.0.1 update failed without any notificaton of such.

I could update Fx 2.0 to 2.0.0.1 with standard user and UAC enabled thanks to the compatibility fix "ElevateCreateProcess". We will have to use ShellExecute in WinLaunchChild if it fails with ERROR_ELEVATION_REQUIRED not to depend on compatibility fix.

This patch also contains a fix for bug 364483.

I'm consider to landing this on 1.8 branch because ElevateCreateProcess shim as well as all other shims will be no longer applied to Fx 2.0.0.3 or later. So all functions which are not available on Win9x should be linked explicitly. Although DuplicateTokenEx is not present on Win95, it doesn't matter because SeaMonkey 1.1 didn't migrate to the toolkit and Fx2 dropped a support for Win95.

This looks good but I haven't tested it on Vista yet. Unless I am mistaken IsUserAnAdmin only checks if the user is the member of the administrators group and not whether elevation is required to perform the required action as is the case for an administrator with UAC enabled.

(In reply to comment #19) As far as I test, IsUserAnAdmin returns FALSE if user is the member of the administrators group and is not elevated. Vista Compatibility Team also recommends to use IsUserAnAdmin to determine whether elevation is required. http://blogs.msdn.com/vistacompatteam/archive/2006/10/05/Command-line-application-with-manifest-asInvoker.aspx

I made and put a patched build on my web space. http://www.oersted.co.jp/~emk/2007/01/fx-351949.zip How to test: 1. Download a NOT latest nightly from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 2. Start nightly and check for update. 3. Click "Later". 4. Close the nightly. 5. Copy the update folder to the patched build. 6. Start the patched build. 7. Make sure elevation dialog is shown. Note that I also applied a patch from bug 354772 because 354772 may prevent updating if you use "Later". Could any Vista testers verify?

> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Sorry, here is only a latest build. Download a slightly older build from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

(In reply to comment #21) > Could any Vista testers verify? > I get an error Message when try to run the patched Build Firefox.exe Application Log: Activation context generation failed for "C:\firefox 3\firefox.exe".Error in manifest or policy file "" on line . A component version required by the application conflicts with another component version already active. Conflicting components are:. Component 1: C:\Windows\WinSxS\manifests\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.112_none_10b2eaaf9bffc879.manifest. Component 2: C:\firefox 3\Microsoft.VC80.CRT.MANIFEST. EventID:78 SidebySide

(In reply to comment #21) I tried your test but the zipped build would not launch for me. I get a couple of error messages like this when I run firefox.exe: Activation context generation failed for "C:\Users\Mark\Desktop\bin\firefox.exe".Error in manifest or policy file "" on line . A component version required by the application conflicts with another component version already active. Conflicting components are:. Component 1: C:\Windows\WinSxS\manifests\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.312_none_10b2ee7b9bffc2c7.manifest. Component 2: C:\Users\Mark\Desktop\bin\Microsoft.VC80.CRT.MANIFEST.

I'll review this today and requesting blocking 1.8.1.2 since we need this for Vista support

The problem with the zip build provided in comment #21 is that the MSVCRT redist is not included. I've done a once over of the patch and it looks good but my tests so far have been unsuccessful. After I figure out what is going on I'll complete the review. Masatoshi Kimura, thank you very much for writing the patch... it is a big help. Would you mind updating the zip build to include the MSVCRT redist so this could be tested more easily?

I attempted to help marcia get the build in comment #21 working, but i failed. (http://msdn2.microsoft.com/en-us/library/ms235342(vs.80).aspx was helpful and useful, though.) If I understand robert's comment #26 correctly, if Masatoshi Kimura would include his msvcr80.dll, msvcp80.dll and msvcm80.dll files, the Microsoft.VC80.CRT.MANIFEST that he already included in his zip would work. (note, his MANIFEST refers to version 8.0.50608.0, but when I attempted to run his firefox.exe without his MANIFEST, the error I got was: Activation context generation failed for "C:\Users\marcia\Desktop\unzipped\bin\firefox.exe". Dependent Assembly Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.

Hm... VC8SP1 seems to cause "Activation Context Hell" :-( I made a patched build again using Windows SDK whose compiler is exactly tha same as VC8 without SP. http://www.oersted.co.jp/~emk/2007/01/fx-351949.zip? I could launch this on WinVista with VC8SP1, WinXP with VC8, and vanilla WinXP (Vitual PC).

(In reply to comment #28) > Hm... VC8SP1 seems to cause "Activation Context Hell" :-( I've filed bug 366820 about this problem.

Bug 366820 is solved, so I built and uploaded once again. I also defined |--enable-update-channel=nightly|. Now you can test more easily: 1. Download and start a patched build. 2. Select [Help] > [Check for Updates...]. 3. Click [Download & Install Now]. 4. Click [Restart Minefield Now] or click [Later] and restart on your own. 5. Make sure elevation dialog is shown.

(In reply to comment #21) > Could any Vista testers verify? > Works for me now with the patched build and update is applied. So i can verify this. However i got a UAC Warning for updater.exe (see Screenshot) but i think this is expected.

Thanks for your test! > However i got a UAC Warning for updater.exe (see Screenshot) but i think this > is expected. Yes, it's expected. We should: 1. Sign the updater.exe (bug 352555). 2. Add a shield icon to the [Restart Minefield Now] button. But they are out of scope for this bug.

With a clean install of Vista RTM the patch is not working for me. The update is downloaded and on restart the update is not applied. This is using the supplied build as well as with a build with the patch applied. I'll continue to investigate what is going on and will review afterwards.

This worked for me when it is *not* installed under program files... not sure why as of yet but I suspect it may have to do with writing to the virtual store when installed in this location.

Elevated process may not refer the another user's profile folder even if its elevated when user makes it private. What about using ProgramData as a update folder on Vista?

I think that may be the way to go... I believe the only issue is with copying the exe over so it may make sense to just copy the exe into the tmp dir instead.

Just a reminder to mark bug 364483 with "fixed1.8.1.2" after this lands.

*IF this patch does indeed fix that bug. :-)

OK, now I understand the reason why "CorrectFilePaths" shim is required. It redirects %ProgramFiles%\Mozilla Firefox\updates to %AppData%\Mozilla\Firefox instead of %LocalAppData%\VirtualStore\...\updates. We will have to do the same job on our own.

This patch uses UserAppDataDir instead of AppDir for update dir. Although I'm not sure whether it's the best place in the world, Microsoft also uses it. I also updated the patched binary. http://www.oersted.co.jp/~emk/2007/01/fx-351949.zip Known bugs: nsPostupdateWin.js will not update the registry keys correctly (bug 354226).

Note: If we decided to use some other place for updater, we will have to consider the migration when updating Fx 2.0.0.2 to 2.0.0.3. 1. Fx 2.0.0.2 downloads the update file into %ProgramFiles%\Mozilla Firefox\updates. Which will be redirected to %AppData%\Mozilla\Firefox. 2. The updater updates firefox.exe as well as some other files. 3. Updater launches Fx 2.0.0.3. 4. Fx 2.0.0.3 will fail to find update dir unless it searches %AppData%\Mozilla\Firefox on its own because Fx 2.0.0.3 is no longer shimmed!

I'm thinking we will be better off in the long run to move the updates dir used for downloading the mar to, etc. to the UserAppDataDir for win32. This would require having a unique path to support side by side installs... perhaps something like UserAppDataDir\mozilla\firefox\<drive>\<relative path to app dir from drive>? Might run into path length restrictions though.

We could shorten the path length using <UserAppDataDir>\Mozilla\Firefox\updates\<relative path to app dir from Program Files>. UserAppDataDir is needed only when we installed under the Program Files. BTW, our installer doesn't support side by side installs on WinVista due to a fix for bug 336469. So I think it doesn't really matter right now.

The installer and the app don't support adding the OS integration reg keys but this won't prevent a second install (e.g. a zip or a installer build launched directly) in program files from trying to use the same location for updates. Just doing this for installs in program files and using the relative path as stated in comment #43 should be sufficient.

Changes: * Previous two patches are merged. * Appended a relative path from Program Files. * Using %LOCALAPPATA% instead of %APPDATA% because update info is local machine specific.

Now nsUpdateService clean up previous update files correctly when updating from 2.0.0.1.

To test the update: 1. Install Firefox 2.0.0.1 2. Set app.update.url.override to https://bugzilla.mozilla.org/attachment.cgi?id=252167 3. Help > Check for Updates... Don't forget to remove app.update.url.override when the test has completed.

Assigning to rstrong to make sure we get this fixed for code freeze tomorrow.

Please note that this patch will not handle post-update correctly. I assumed it would be resolved by bug 354226.

some comments from when robert and I reviewed and tested this patch. robert has fixed #1 and #4 locally in his tree, the rest of the cleanup will be spun off to new bugs. 1) + // See the local appdata first if app dir is under Program Files. + var file = null; + var updRoot = getFile(KEY_APPDIR); + var programFilesDir = fileLocator.get(KEY_PROGRAMFILES, + Components.interfaces.nsILocalFile); + if (programFilesDir.contains(updRoot, true)) { + var relativePath = updRoot.getRelativeDescriptor(programFilesDir); + var userLocalDir = fileLocator.get(KEY_LOCALDATA, + Components.interfaces.nsILocalFile).parent; + updRoot.setRelativeDescriptor(userLocalDir, relativePath); + file = appendUpdateLogPath(updRoot); + + // When updating from Fx 2.0.0.1 to 2.0.0.3 (or later) on Vista, + // we will have to see also user app data (see bug 351949). + if (!file) + file = appendUpdateLogPath(getFile(KEY_UAPPDATA)); + } + + // See the app dir if not found or app dir is out of Program Files. + if (!file) + file = appendUpdateLogPath(getFile(KEY_APPDIR)); during his review (and testing), robert found problems with the above JS: he needed to get the fileLocator and he needed to QI updRoot to nsILocalFile to get the relative descriptor. he added: + var fileLocator = Components.classes["@mozilla.org/file/directory_service;1"] + .getService(Components.interfaces.nsIProperties); and he also added: + var relativePath = updRoot.QueryInterface(Components.interfaces.nsILocalFile). + getRelativeDescriptor(programFilesDir); 2) I'd prefer is this fourth param was an enum. + WinLaunchChild(argv[0], argc, argv, -1); +WinLaunchChild(const char *exePath, int argc, char **argv, int needElevation); + * @param needElevation 1:need elevation, -1:want to drop priv, 0:don't care 3) + nsCOMPtr<nsILocalFile> updRootl(do_QueryInterface(updRoot)); maybe we could pick a better name than updRootl? 4) + char path[MAX_PATH]; + rv = GetShellFolderPath(CSIDL_PROGRAM_FILES, path); +#ifdef XP_WIN +static nsresult +GetShellFolderPath(int folder, char result[MAXPATHLEN]) Why MAX_PATH vs MAXPATHLEN. We should match those match.

> Assigning to rstrong to make sure we get this fixed for code freeze tomorrow. re-assign to Masatoshi Kimura, as he was the author of the patch. Robert asked me to re-assing to him, so he get credit, and to thank him for doing all this work for Vista support!

Fixed on trunk. Thanks again Masatoshi Kimura. I'll make sure this lands on MOZILLA_1_8_BRANCH, etc.

Just talked with Jay and we are going to hold off on landing this on the branch until possibly Monday since this is interdependent on the other patches and we want to bake everything through the Friday test day on trunk

fix landed on branch.

just filed bug 369627 on nsXULStub.cpp (WinLaunchChild) bustage when building xulrunner 1.8 branch xulStub :) https://bugzilla.mozilla.org/show_bug.cgi?id=369627

Comment on attachment 252165 [details] [diff] [review] patch v4 Checked in with changes