310362 - Show Update History in Options panel displays "Status: Install Pending" and "Firefox 1.4 (undefined)" for update that has just been installed.

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Weston Carloss]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050928 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050928 Firefox/1.4 ID:2005092806

The title pretty much explains everything.  After updating from 20050927 nightly
build to the 20050928 nightly build, the update history displays an incorrect
status for the installation as well as no build/update ID.

Reproducible: Always

Steps to Reproduce:
1.  Download the 2005092706 nightly branch build.
2.  Click "Check for Updates..." to update to the 20050928 nightly build.
3.  Go to Tools -> Options -> Advanced -> Updates -> Show Update History

Actual Results:  
"Show Update History" displays the following:

Firefox 1.4 (undefined)
Security Update
Installed on: "Correct day of the week, month, day of the month, year and time
of day)
Status: Install Pending 

Expected Results:  
Status should say something like "Install successful" or simply "Installed."
Also, "undefined" should probably be a build number or a patch name/number.


Auto update has been slow for me recently so I can't confirm whether the issue
happens with auto update as well, although I assume it does.  One other person
on the MozillaZine forums has reported this issue on Windows ME, but it may
affect every OS.  Based on my experience, as well as the experience of one other
user on the forums, the issue appears whether the 20050927 is a brand new
install or an update from an older build.  Also, a new profile does not change
the behavior.

Comment 1

[Peter van der Woude [:Peter6]]

Attachment: dialog 3 stages

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050927
Firefox/1.4 ID:2005092813

Confirmed

Comment 2

[Asa Dotzler [:asa]]

darin and ben, can you tell us what's going on here and if this is "expected" or
not? Could it just be an issue with nightly build updates?

Comment 3

[Patrick Lee]

Something else that I'm noticing is that only the most recent update is listed
in the Update History.  As Asa suspects, this may just be related to the nightly
updates.  Ideally we would have a complete listing of the updates applied since
the initial install (in reverse chronological order I suppose).

A related question would be if we build up an update history through diff
patches and then use a full installer, does that wipe out the history?  Or does
it show up as just another update like the diffs?

Comment 4

[Weston Carloss]

Patrick, I agree that the update history should show all updates in reverse
chronological order and I have a feeling that eventually the system will be set
up that way.  

Here's how I'd like the update history to look.  If the software is updated
through a small binary then the update should be labeled as "Firefox 1.4
(patch/build number - Binary Update)".  If the update was performed using one of
the large 6.0Mb mar files it could be labeled "Firefox 1.4 (patch/build - Full
Install)".  Finally, if the software is a brand new install, a new install on
top of an old one, or if an old version is uninstalled and a new version
installed, the update history should be cleared and a new entry added that says
"Firefox 1.4 (build number) - New Install".  "New Install" and "Full Install"
might be too similar and confusing, but I'm just trying to say that it would be
neat if the install/update methods were labeled.  I realize that changing this
much in the update history, and probably the installer, is probably a lot of
work, which would benefit mostly nightly testers, but I wanted to toss out the
idea.  If my plan is too large to implement in 1.5, I'd appreciate it if
something similar could be worked out for 2.0+.  If at all possible, a complete
list of updates in reverse chronological order would be really nice for 1.5,
even if it's still being tweaked for future versions.

Comment 5

[Asa Dotzler [:asa]]

not going to block on this.

Comment 6

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

The list of updates in the prefs is pulling its information directly from 
updates.xml, which is written every time an update occurs. That file, in turn, 
is written with data that comes from the update.xml file delivered by AUS.

The 'undefined' line is indeed supposed to be the buildID. It seems that AUS 
is not sending any 'buildID' tag, so when the update manager tries to write 
the file it is just sticking 'undefined' in there. I've verified that, if you 
intercept the update.xml file and add a 'buildID' tag, the value will 
propogate correctly into the prefs. It will take a server-side fix to make 
this show up correctly unless we want the buildID tag to be generated client-
side.

The 'Install Pending' line is also coming from updates.xml, so updater.exe 
isn't rewriting the updates.xml file when it finishes applying an update. I 
haven't had a chance to look into how to fix this one yet.

Comment 7

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

Actually, updater.exe is reporting patch success correctly and has nothing to 
do with rewriting updates.xml (see comment #6). We can fix this one in 
nsUpdateService.js so that the history displays correctly.

Comment 8

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

*** Bug 312447 has been marked as a duplicate of this bug. ***

Comment 9

[Asa Dotzler [:asa]]

Who from AUS can help here?

Comment 10

[Chase Phillips]

This was in a dev instance of AUS previously.  Developers did not get back to us
in time and missed the cycle.  This will be in the next deployed version of AUS.
 No date attached but intention is prior to our next 1.5 rc release.

Comment 11

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

Created bug 312670 to take care of the "Install Pending" line. The failure is 
in the UpdateManager componnent, so an AUS fix isn't going to affect this 
problem at all. 

Comment 12

[Chase Phillips]

Mike Morgan has deployed the new version of AUS2 to production.  The build ID
attribute is now sent to clients that request an update.

Also noting that this bug's fix depends on bug 312670.

Comment 13

[Jay Patel [:jay]]

v.fixed on trunk and branch.  I was able to successfully update from 10/19
builds up to today, and saw the build id get updated in update history after
each update was applied.

Comment 14

[Jay Patel [:jay]]

I tested both Firefox and Thunderbird on WinXP for the trunk and branch... and
can verify that the Update History properly displays each nightly update I
applied.  The Build ID is there now, but the "Status: Install Pending" bug is
still there.

Comment 15

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

The fix for bug 312670 hasn't landed on the branch yet... Did you see 
the 'Install Pending' line on the trunk build, too?

Comment 16

[Nikola Kocić]

(In reply to comment #15)
> The fix for bug 312670 hasn't landed on the branch yet... Did you see 
> the 'Install Pending' line on the trunk build, too?

Yes, there is "Install Pending" bug on trunk

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20051021
Firefox/1.6a1 ID:2005102106