351949 - Automatic Update is not working for Vista users with limited account privilege and UAC (User Account Control) enabled

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[matthaeus123]

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.

Comment 1

[Colin Jeanne]

(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?

Comment 2

[matthaeus123]

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

Comment 3

[Robert Strong (they/them - no direct email)]

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.

Comment 4

[Carl Schrader]

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)

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 6

[Landon Abney]

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)

Comment 7

[Ant Bryan]

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.

Comment 8

[-fullmetaljacket-]

confirmed!

this is my problem since i upgraded to vista.

Comment 9

[-fullmetaljacket-]

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

Comment 10

[-fullmetaljacket-]

(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"

Comment 11

[-fullmetaljacket-]

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

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

(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. 

Comment 13

[-fullmetaljacket-]

maybe it had something to do with bug# 364628

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

(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.

Comment 15

[Scott]

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

Comment 16

[Masatoshi Kimura [:emk]]

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.

Comment 17

[Masatoshi Kimura [:emk]]

Attachment: like this

This patch also contains a fix for bug 364483.

Comment 18

[Masatoshi Kimura [:emk]]

Attachment: link to IsUserAnAdmin explicitly

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.

Comment 19

[Robert Strong (they/them - no direct email)]

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.

Comment 20

[Masatoshi Kimura [:emk]]

(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

Comment 21

[Masatoshi Kimura [:emk]]

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?

Comment 22

[Masatoshi Kimura [:emk]]

> 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/

Comment 23

[Carsten Book [:Tomcat]]

Attachment: error message when starting firefox.exe

(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

Comment 24

[Mark Takeuchi]

(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.

Comment 25

[Robert Strong (they/them - no direct email)]

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

Comment 26

[Robert Strong (they/them - no direct email)]

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?

Comment 27

[(not reading, please use [e-mail] instead)]

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.

Comment 28

[Masatoshi Kimura [:emk]]

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).

Comment 29

[Masatoshi Kimura [:emk]]

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

Comment 30

[Masatoshi Kimura [:emk]]

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.

Comment 31

[Carsten Book [:Tomcat]]

Attachment: UAC Updater.exe Warning

(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.

Comment 32

[Masatoshi Kimura [:emk]]

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.

Comment 33

[Robert Strong (they/them - no direct email)]

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.

Comment 34

[Robert Strong (they/them - no direct email)]

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.

Comment 35

[Masatoshi Kimura [:emk]]

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?

Comment 36

[Robert Strong (they/them - no direct email)]

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.

Comment 37

[Jay Patel [:jay]]

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

Comment 38

[Jay Patel [:jay]]

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

Comment 39

[Masatoshi Kimura [:emk]]

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.

Comment 40

[Masatoshi Kimura [:emk]]

Attachment: Additional patch making updater work under Program Files

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).

Comment 41

[Masatoshi Kimura [:emk]]

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!

Comment 42

[Robert Strong (they/them - no direct email)]

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.

Comment 43

[Masatoshi Kimura [:emk]]

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.

Comment 44

[Robert Strong (they/them - no direct email)]

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.

Comment 45

[Masatoshi Kimura [:emk]]

Attachment: patch v3

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.

Comment 46

[Masatoshi Kimura [:emk]]

Attachment: patch v4

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

Comment 47

[Masatoshi Kimura [:emk]]

Attachment: Fake update.xml

Comment 48

[Masatoshi Kimura [:emk]]

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.

Comment 49

[Jay Patel [:jay]]

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

Comment 50

[Masatoshi Kimura [:emk]]

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

Comment 52

[(not reading, please use [e-mail] instead)]

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.

Comment 53

[(not reading, please use [e-mail] instead)]

> 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!

Comment 54

[Robert Strong (they/them - no direct email)]

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

Comment 55

[Robert Strong (they/them - no direct email)]

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

Comment 56

[(not reading, please use [e-mail] instead)]

fix landed on branch.

Comment 57

[Mel Reyes]

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 58

[Robert Strong (they/them - no direct email)]

Comment on attachment 252165 [details] [diff] [review]
patch v4

Checked in with changes