Closed Bug 311539 Opened 17 years ago Closed 17 years ago
A Null in the Updates Folder Gives False Indication
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051007 Firefox/1.4.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Thunderbird/1.4.1 - Build ID: 2005100614 I've seen this a few times with TB. If you look at the update status file (sorry, don't remember the precise file name) in the TB Updates\0 folder, and the contents say "Null", if you then restart TB, you will be told that there is an update available, followed by (Null). If you tell the Updater to get the update, you will never find it; the pop-up with (NULL) is a false indication of an available update. I've only seen the file for Firefox that said "null" once that I recall; I believe that I restarted FF and did not get the pop-up notification, but I am quite uncertain about this. Reproducible: Always Steps to Reproduce: 1. As stated above, if you happen to restart TB when the Updates/0 file has the word "Null" in it, you will get a notiifcation of an available Update (NULL). 2. Click on the button to get the update. 3. Actual Results: Nothing, because there is apparently no such update available: The (NULL) is a nullity. Expected Results: I would not expect to be notified of a null update.
I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051008 Thunderbird/1.4.1 - Build ID: 2005100806. Still broken: For several hours, the"0" folder has had a `null' entry in update.status. I waited to see if that would change. When it did not, I clicked on Help, Check for Updates, was told that TB 1.0+ was ready. (I know about the false release indication, which was true for Firefox also.) The Software Update module started, said it was connecting to the server, and included this text: "Thunderbird was unable to verify the integrity of the incremental update it downloaded, so it is now downloading the complete update package." I waited several minutes; the update server was never contacted. I removed the update.status file, restarted TB, again clicked on help, check: The software update module has now been running for ten minutes, without ever contacting the update server. (There is no change in update.status, nor is there a .mar file in the "0" folder. I'm changing the severity to major, and am tempted to change it to critical: This behavior is unacceptable and, if it persists into the release, will cause a great deal of trouble and confusion. Ah! I see at least part of the problem, I believe: The latest .mar/installer files in http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/ are dated 08 Oct. 05. That indicates to me that the update mechanism should not be showing that an update is even available--and if none is available, would also indicate to me why it never contacts the server at this time. Still buggy, in other words.
Severity: normal → major
I experienced this bug too. Recently, there was no partial mar file for 2005-10-22-11 nightly branch build and I got the "Null" update window every time I checked for updates (see attachment).
This is now being reported for Firefox: http://forums.mozillazine.org/viewtopic.php?t=333307 Reports start on page one, from CrazyFred.
Status: UNCONFIRMED → NEW
Component: Installer → General
Ever confirmed: true
Product: Thunderbird → AUS
Version: unspecified → 1.0
No Software Updates component in Thunderbird. Moving it to Firefox since I suspect the problem applies there as well.
Component: General → Software Update
Product: Thunderbird → Firefox
Version: 1.0 → 1.0 Branch
Target Milestone: --- → Firefox1.5rc1
Version: 1.0 Branch → 1.5 Branch
Both Asa and myself saw this in Firefox after our update from 2005102105 to 2005102322. Recall that now 2005102322 has been removed from the update system, so 2005102105 updates to 2005102400.
Following all the testing Chase did last night in fixing the AUS, and then the issues with the bad patch, I skipped right to 2005102400 build, manual download, and installed over yesterday's nightly - 2005102305. I then ran 'Check for Updates' and it installed a 240k updated to todays nightly 2005102404. Now everytime I restart Firefox I get an update notice showing 'Null'... the throbber spins but never goes anywhere. I have deleted updates.xml and active-update.xml, and continue to see the Null update. Look at the update log it shows it succeeded. Also.. When I look at the 'Update History' it still shows 'Install Pending' Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 ID:2005102404
This could be related to bug 313623 as updates/0 should be deleted after it is applied. If update.status as written contains "null" and updates/0 is not deleted before the app starts up, according to this bug the Firefox (null) software update dialog will appear.
(In reply to comment #9) > This could be related to bug 313623 as updates/0 should be deleted after it is > applied. If update.status as written contains "null" and updates/0 is not > deleted before the app starts up, according to this bug the Firefox (null) > software update dialog will appear. > Deleting the contents of updates/0 did clear the 'Null' update on restart of Fx. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 ID:2005102404
I've seen the update service get into this bad state as well. Usually, it happened when something failed that shouldn't have failed. I think we should try to make the update service correct itself if it ever happens to end up in this state.
Assignee: mscott → darin
This patch cleans up after an update that gives a 'null' status so that it won't display the misleading UI. This patch does not address how an update is getting a 'null' status in the first place...
Attachment #200675 - Flags: review?(darin)
Oh, I guess I should add that this patch will only work if the patch for bug 313623 is applied (so that the cleanup function actually does what it's supposed to!).
I'll review this since darin is busy...
Comment on attachment 200675 [details] [diff] [review] patch v1.0 This looks fine for this one condition. I know that there are additional error conditions that we may or may not run into in practice, e.g. status = "failed" and update.selectedPatch = null... This may be the condition when a complete update fails to apply. I think in that case we want to show the manual update page, reset everything and allow the user to start over.
Attachment #200675 - Flags: review?(darin) → review+
Still working on this or should we nom for approval (or just approve)?
Comment on attachment 200675 [details] [diff] [review] patch v1.0 Let's go with this. BenG said he was going to look into other potentially problematic cases. This patch fixes a problem that has been known to appear in the wild, so we should at least fix it.
Attachment #200675 - Flags: approval1.8rc1?
Attachment #200675 - Flags: approval1.8rc1? → approval1.8rc1+
Should we resolve this bug?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.