User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060213 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060213 Firefox/1.6a1 when trying to update fx 1.6a1 after updating to build 20060213, fx will not update to build 20060214 Reproducible: Always Steps to Reproduce: 1.Under the help menu, click check for updates. 2.Click next on every dialog, then click restart Deer Park. 3.Software Update window ("Firefox is installing your updates and will start in a few moments.") does not appear and build ID stays at 20060213 in About. Alternate reproduction method: 1.Wait for software update window to pop up suddenly, asking you to restart 2.Restart fx and update windows will not appear Actual Results: Update progress window does not appear and fx will remain unupdated Expected Results: fx should update to the next day's build
I'm seeing the same behavior with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060214 Firefox/1.6a1 ID:2006021405 Requesting STATUS: NEW
I believe this is caused by bug 327140. The Firefox bug would be that no error is reported (similar to bug 326465, which is marked Mac only and seems to be specific to yahoo packaging).
I don't think there is a bug on the Firefox side, it's all bug 327140. Replying to the original post: The partial update files are effectively empty - there are no items to update in the file that controls the process, update.manifest - so the BuildID never updates. The "update" is very quick, so that the update progress UI is never shown. Replying to Josh: As far as the the updater executable is concerned, it's done it's job flawlessly - nothing to do, so not surprisingly no error. I guess you could argue that Firefox should check on restart that its new BuildID matches what was offered in the update.xml, and fallback to the full update if it doesn't. The startup logic is already reasonably complicated though. It's a question of where you want to make the system more robust, in the client or the server. In this case, it's a case of bullsh*t in, bullsh*t out.
*** This bug has been marked as a duplicate of 327140 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.