If there is a full update in the que and a current nightly is installed over it the older update is installed over the current nightly. Install Firefox Beta 2 Edit the channel-prefs.js to nightly Check for updates Choose install later Close Firefox Delete update.mar Create a blank update.mar Open Firefox Check for updates, a full update should be downloaded Choose install later Download a current nightly and install Upon first launch the update will install the update I would expect the updater not to install the update if the current build ID is larger than the update ID.

I don't think we will be fixing this for FF 1.5

I don't think we should block FF 1.5 for this.

Are buildId's included in .mar files at the moment?

*** Bug 321849 has been marked as a duplicate of this bug. ***

I don't do anything with .mar files. I just download the latest installer.exe, but I'm seeing the same problem (Minefield just downgraded my 20060531 nightly to 20060528 after the automatic update). I presume it's the same bug as this? Adding a few more keywords to the Summary for ease of finding.

I just had this happen to me with Firefox 3 beta 3 pre. I had a build of 01-12-08 that downloaded from the nightly build location and installed manually (copied files from a zip file to the installation directory), and the updater replaced it with 2008011105.

This is a really annoying issue which I was also able to see today while trying to upgrade the Firefox version from 2.0.0.11 to 2.0.0.13 for a co-worker: 1. Complete .mar file was downloaded and update dialog appears 2. Started update process which failed due to limited disk space 3. Patching firefox.exe failed => Installed version is not usable anymore 4. Uninstalled Firefox 2.0.0.11 5. Installed Firefox 2.0.0.13 6. Started Firefox Now the update dialog comes up again and tells that a previous update wasn't successful (which is still correct) applied and has to retried. Now you can click on restart and the already downloaded 2.0.0.13 update will overwrite your currently installed version. It seems that there is no version check at the moment. The file active-update.xml contains the target version of the downloaded update which should have to be compared against the currently installed version before the update notice is shown. If it contains the same or a lesser version the downloaded update has to be rejected and deleted from disk. At the moment you will be able to overwrite an existing Firefox version with an out-dated version. It depends on which version was downloaded for the current user and when he was logged-in the last time. If he has admin permissions and hasn't used his account for a half year the Firefox version will be downgraded to the version which was up-to-date at this time. Requesting blocking-firefox3 because it's a major issue and the fix shouldn't be too hard to implement.

This does not block the final release of Firefox 3.

The buildID format may change and afaik isn't used for comparison in the code base both of which make me extremely uncomfortable so I used the app version instead. In the case where they are equal we apply the update which shouldn't leave an unusable app except possibly in the nightly user case.

Comment on attachment 347603 [details] [diff] [review] patch rev2 a=beltzner

Pushed: http://hg.mozilla.org/mozilla-central/rev/4db7b751339e

In case we want to take this for a 1.9.0.x release... still need to let the trunk patch bake a bit

Comment on attachment 349083 [details] [diff] [review] patch for 1.9 (checked in) This has been baking on the trunk and on 1.9.1 for quite some time so requesting approval 1.9.0.x. This prevents downgrading to an earlier version when an update has been staged to be installed.

Comment on attachment 349083 [details] [diff] [review] patch for 1.9 (checked in) I think we'll let this one go for 1.9.0.x, we've had it for a really long time, and I don't think there's a ton of incidents happening with this bug, so let's just let it get fixed in 3.1.

Taking this well-baked fix on the 1.9.0 branch will resolve a bug that mystifies and alarms users on shared computers.

Comment on attachment 349083 [details] [diff] [review] patch for 1.9 (checked in) Approved for 1.9.0.12, a=dveditz for release-drivers

Comment on attachment 349083 [details] [diff] [review] patch for 1.9 (checked in) Checking in mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in; /cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v <-- nsUpda teService.js.in new revision: 1.152; previous revision: 1.151 done Checking in mozilla/toolkit/xre/nsAppRunner.cpp; /cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v <-- nsAppRunner.cpp new revision: 1.217; previous revision: 1.216 done Checking in mozilla/toolkit/xre/nsUpdateDriver.cpp; /cvsroot/mozilla/toolkit/xre/nsUpdateDriver.cpp,v <-- nsUpdateDriver.cpp new revision: 1.27; previous revision: 1.26 done Checking in mozilla/toolkit/xre/nsUpdateDriver.h; /cvsroot/mozilla/toolkit/xre/nsUpdateDriver.h,v <-- nsUpdateDriver.h new revision: 1.5; previous revision: 1.4 done

For record-keeping, this caused bug 498379

Verified by installing an older nightly, checking for updates but not applying it, installing a more recent nightly, and then upon first start of the latter installation the expected version was shown as having been installed. No update to the latest nightly. Also tried installing older nighly, checking for update but not applying it, installing the latest nightly...and so on such that the application did not install the pending update. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.12pre) Gecko/2009070606 GranParadiso/3.0.12pre (.NET CLR 3.5.30729) Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.12pre) Gecko/2009070604 GranParadiso/3.0.12pre

Also verified on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090706 Shiretoko/3.5.1pre and its Vista version

Not for 1.8, right?