fx 1.6a1 does not update after updated to build 20060213

RESOLVED DUPLICATE of bug 327140

Status

()

Toolkit
Application Update
--
major
RESOLVED DUPLICATE of bug 327140
13 years ago
10 years ago

People

(Reporter: Charli Li (winsxs), Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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
(Reporter)

Updated

13 years ago
Version: unspecified → Trunk

Comment 1

13 years ago
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

13 years ago
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
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.