368082 - update history status says "Install Pending" after major update

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[juan becerra [:juanb]]

Attachment: updates file after a major update

Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

The update history Status says "Install Pending" after a major update from 1509 to 2001. The update seems fine, but the Status is incorrect. I've attached the updates.xml file after the update.

STR:
1. Install 1509 and set the update channel to "releasetest"
2. Restart and Check for Updates
3. Install major update and check Options/Advanced/Updates show update history

Expected: Status should say success or installed...

Actual: Update status says "Install Pending"

Comment 1

[Carsten Book [:Tomcat]]

Attachment: updates.xml from a 1508-1509 update

Comment 2

[Carsten Book [:Tomcat]]

If you compare the update.xml from the major update and from a 1508->1509
Update you see difference (don`t know if this important) that1508->1509 has :

 <patch type="complete" URL="http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/1.5.0.9-candidates/rc1/firefox-1.5.0.9.en-GB.win32.complete.mar"
    hashFunction="SHA1" hashValue="74574d055502121ef108b25843787ddabcc8e7e8"
    size="6397385" selected="true" state="" />
      <patch type="partial"
    URL="http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/1.5.0.9-candidates/rc1/firefox-1.5.0.8-1.5.0.9.en-GB.win32.partial.mar"
    hashFunction="SHA1" hashValue="4b0390a6aa7ddd46072d0efc02be36796dde51b2"
    size="522499" selected="false" state="" />

    and on 2001 the state is null

      <patch type="complete"
    URL="http://download.mozilla.org/?product=firefox-2.0.0.1-complete&os=win&lang=en-US"
    hashFunction="SHA1" hashValue="7474c3868aa580a7175c86caa6db65e806bf36c0"
    size="7584043" selected="false" state="null" /> 
      <patch type="partial"
    URL="http://download.mozilla.org/?product=firefox-2.0.0.1-complete&os=win&lang=en-US"
    hashFunction="SHA1" hashValue="7474c3868aa580a7175c86caa6db65e806bf36c0"
    size="7584043" selected="true" state="null" /> 

Comment 3

[Carsten Book [:Tomcat]]

Attachment: also updates.xml from 2000 -> 2001 partial

Comment 4

[juan becerra [:juanb]]

Attachment: updates file after downloading major update, but before applying

I'm attaching the updates.xml file after downloading a major update 1509-2001 es-ES, but before applying it.

Comment 5

[Marcia Knous [:marcia]]

Just checked my updates.xml file after a major update on Win Vista, and I see the same thing that Juan does, statusText=Install Pending.

Comment 6

[Carsten Book [:Tomcat]]

Also confirmed for Linux, so "Install Pending" confirmed for Windows, Linux, Mac

Comment 7

[(not reading, please use [e-mail] instead)]

I'm investigating this.  
thanks to marcia, juan and carsten for all the info so far.

it makes me (and jay,dveditz,and others) nervous not knowing the root cause, as it might be an indication of a bigger problem.

I can reproduce as well with 1509 -> 2001 on the releasetest channel, per juan's steps.

so far, it looks like the update.status file is not found (under updates\0\update.status), which I believe leads the this problem.

from my procmon, I see that we are removing it, but i can't tell what is removing it yet.

Comment 8

[(not reading, please use [e-mail] instead)]

Attachment: output from procmon

Comment 9

[(not reading, please use [e-mail] instead)]

good news, finally!  here's what's going on:

on the releasetest channel for the major update (1.5.0.9 -> 2.0.0.1), the update snippet that we download does not have the channel parameter set, for example:  channel="releasetest".  (see carsten's example, which has channel="release" https://bugzilla.mozilla.org/attachment.cgi?id=252651)

the snippet does have the serviceURL attribute, for example serviceURL="https://aus2.mozilla.org/update/1/Firefox/1.5.0.9/2006120612/WINNT_x86-msvc/en-US/releasetest/update.xml"

note:
in 1.5.0.x, we use the serverURL to determine if we should clear out any old active updates, because the user switched channels.  see http://lxr.mozilla.org/mozilla1.8.0/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1582

in 2.0.0.x, we use the channel to determine this see http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1635

so, our the update in our snippet does not have a channel (so we use the default value of "default"), but our app.update.channel pref values is "releasetest").

so, the update succeeds, and to update.status we write "succeeded".

but, then we execute the code that detects our channel has changed ("default" != "releasestest"), so we remove the updates\0 directory, including the update.status file.

because that file has been removed, we never read it, and change update.statusText from "Install Pending" to "The Update was successfully installed".

I've verified that adding channel="releasetest" to my active-update.xml snippet fixes this problem.

here comes the part where I owe preed/morgamic/rhelmer yet another bottle of scotch:

if we want to fix this for the 1.5.0.9 -> 2.0.0.1 major update, we need to include the channel attribute in the snippets we serve.

Comment 10

[(not reading, please use [e-mail] instead)]

note, juan was onto this at around 5:45 pm:

The files look different structurally between 1.5x and 2x in these cases, but there are also differences between 2.0-2001 in the types of values for certain attributes. For instance 1.5x doesn't have a "channel" attribute; but in the 2->2001 updates the "channel" attribute is set to "release", whereas the 1509-2001 "channel" attribute is set to "default." 

Comment 11

[(not reading, please use [e-mail] instead)]

steps to verify the suggested fix:

1. Install 1509 and set the update channel to "releasetest"
2. Restart and Check for Updates
3. Download major update, but do not install
4. exit app
5. add channel="releasetest" to update in active-update.xml
6. restart firefox which will apply update
7. check Options/Advanced/Updates show update history

should now say:  "The Update was successfullyinstalled".

Comment 12

[Carsten Book [:Tomcat]]

(In reply to comment #11)
> steps to verify the suggested fix:

Seth, i can verify your suggested fix (adding channel="releasetest" to active-update.xml).

-> installDate="1169723467319" statusText="The Update was successfully installed" buildID="2006120418" isCompleteUpdate="false" channel="releasetest">

Comment 13

[Robert Helmer [:rhelmer]]

Hey Seth,

I don't see a "channel" attribute in any of the update.xml files we serve up now:

(2.0->2.0.0.1)
https://aus2.mozilla.org/update/2/Firefox/2.0/2006101023/WINNT_x86-msvc/en-US/releasetest/update.xml

(1.5.0.8->1.5.0.9)
https://aus2.mozilla.org/update/1/Firefox/1.5.0.8/2006102516/WINNT_x86-msvc/en-US/releasetest/update.xml

(1.5.0.9->2.0.0.10
https://aus2.mozilla.org/update/1/Firefox/1.5.0.9/2006120612/WINNT_x86-msvc/en-US/releasetest/update.xml

The only place I see "releasetest" in these is the URL; none of the text snippets these are build from have the channel either AFAICT.

Comment 14

[(not reading, please use [e-mail] instead)]

rob and morgmaic:  

> I don't see a "channel" attribute in any of the update.xml files we serve up
> now

right.  I'm asking that we add it for the 1.5.0.9 -> 2.0.0.10 major update snippet to fix this bug for 1.5.0.9.

when 1.5.0.9 gets the snippet, it uses the serviceURL attribute (and not the channel attribute, like 2.0+).  

for 1.5.0.10 users, the client side fix for this bug would be to also set the .channel attribute so that we'll persist it to disk, when we write out active-updates.xml (and updates.xml).

Comment 15

[(not reading, please use [e-mail] instead)]

as discussed in the meeting today, the plan is to fix this on the client side for 1.5.0.10, and to not push the major updates to 1.5.0.9 users.

Comment 16

[(not reading, please use [e-mail] instead)]

Attachment: low risk patch, testing now

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: correct patch

Comment 18

[(not reading, please use [e-mail] instead)]

Attachment: patch that works, how about that?

Comment 19

[(not reading, please use [e-mail] instead)]

Attachment: active-update.xml from my 1.5.0.9 -> 2.0.0.1 major upgrade on the releasetest channel

Comment 20

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of my update history dialog (in 2.0.0.1, after the major)

Comment 21

[(not reading, please use [e-mail] instead)]

Comment on attachment 253050 [details] [diff] [review]
patch that works, how about that?

seeking r= from dan

Comment 22

[(not reading, please use [e-mail] instead)]

Comment on attachment 253050 [details] [diff] [review]
patch that works, how about that?

seeking robert's review, too.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 253050 [details] [diff] [review]
patch that works, how about that?

r=dveditz

Comment 24

[Robert Strong (they/them - no direct email)]

Comment on attachment 253050 [details] [diff] [review]
patch that works, how about that?

r=rob_strong

Comment 25

[Jay Patel [:jay]]

Comment on attachment 253050 [details] [diff] [review]
patch that works, how about that?

Approved for 1.8.0 branch, a=jay

Comment 26

[(not reading, please use [e-mail] instead)]

fixed on the MOZILLA_1_8_0_BRANCH only (this is not going into trunk or MOZILLA_1_8_BRANCH).

this fix will also benefit tbird major updats from 1.5.x -> 2.x

Checking in nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpda
teService.js.in
new revision: 1.77.2.25.2.5; previous revision: 1.77.2.25.2.4
done

Comment 27

[(not reading, please use [e-mail] instead)]

jay, juan and I had a brief "uh oh" moment over this patch yesterday.  (luckily, preed and tony helped us verify we were ok.)  here's what happened:

my patch to 1.5.0.10 only uses the app.update.channel pref to determine the channel value.  but the branch and trunk use a more elaborate version that also uses app.partner.* pref branch to dynamically determine the channel name (see http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#516)
)

we were concerned that these two would not generate the same value, and all partner builds would still have this "Install Pending" bug.  But, it turns out that for trunk and MOZILLA_1_8_BRANCH bsmedberg fixed it so we dynamically create the channel (see bug #351714).

but back on the MOZILLA_1_8_0_BRANCH, we just relied on the app.update.channel pref.

tony helped us confirm this by letting us look at some 1.5.0.x partner builds, as well as some 2.0 partner builds.

Comment 28

[Jay Patel [:jay]]

v.fixed on 1.8.0 branch after testing both minor and major update paths (1/29 -> 1/30 using special nightly builds)

Comment 29

[Al Billings [:abillings - ex-MoCo]]

This seems broken. I just did the 1.5.0.12 --> 2.0.0.6 major update. Afterwards, when looking at the Update History, it says "No updates installed yet."

This is on Windows XP.

Comment 30

[Robert Helmer [:rhelmer]]

(In reply to comment #29)
> This seems broken. I just did the 1.5.0.12 --> 2.0.0.6 major update.
> Afterwards, when looking at the Update History, it says "No updates installed
> yet."
> 
> This is on Windows XP.

Hmm.. might this have to do with the directory that updates are stored in changed during the 2.x release line (for better Vista support)?

Can you open a new bug for this? I think it's a different issue.

Comment 31

[Al Billings [:abillings - ex-MoCo]]

New bug is Bug 395984.