311539 - A Null in the Updates Folder Gives False Indication

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[John Liebson]

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.

Comment 1

[John Liebson]

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.

Comment 2

[Adam Kowalczyk]

Attachment: "null" update window

Comment 3

[Adam Kowalczyk]

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

Comment 4

[John Liebson]

This is now being reported for Firefox:

http://forums.mozillazine.org/viewtopic.php?t=333307

Reports start on page one, from CrazyFred.

Comment 5

[Chase Phillips]

No Software Updates component in Thunderbird.  Moving it to Firefox since I suspect the problem applies there as well.

Comment 6

[Chase Phillips]

blocking1.8rc1?

Comment 7

[Chase Phillips]

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.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 9

[Chase Phillips]

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.

Comment 10

[Jim Jeffery not reading bug-mail 1/2/11]

(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

Comment 11

[Darin Fisher]

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.

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch v1.0

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

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

I'll review this since darin is busy... 

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 16

[Mike Schroepfer]

Still working on this or should we nom for approval (or just approve)?

Comment 17

[Darin Fisher]

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.

Comment 18

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Should we resolve this bug?

Comment 19

[Darin Fisher]

fixed-on-trunk, fixed1.8