327394 - fx 1.6a1 does not update after updated to build 20060213

Status: RESOLVED DUPLICATE of bug 327140

(Toolkit :: Application Update, defect)

Description

[Charli Li (winsxs)]

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

Comment 1

[Ronald Tilby]

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

Comment 2

[Josh Birnbaum]

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

Comment 3

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

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.

Comment 4

[Steve England [:stevee]]

*** This bug has been marked as a duplicate of 327140 ***