299736 - Manual "Check for Updates" finds updates when none exist; gets stuck / tries "Connecting to server..." foreever

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

To reproduce:

1. Install a Deer Park build from the day before (earliest: 20050704)
2. In about:config, replace the value of app.update.url with
"https://aus-staging.mozilla.org:8711/update2/0/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/update.xml"
3. Under Help menu, select "Check for Updates ..."
4. Accept the certificates, install the update
5. Restart the browser
6. Under Help menu, select "Check for Updates ..."

Expected Results:
No update should be found.

Actual Results:
Update is found, but when you try clicking "Install" the software update UI
tries "Connecting to Server ..." forever (and the throbber doesn't throb).
Clicking "Back" from this point results in a blank wizard page with the title
"Software Update" and "Finish" and "Cancel" buttons. The "Finish" button is
enabled and set to default action. Clicking "Finish" or "Cancel" does nothing,
and the window can only be closed using the w32 window close button.

Notes: 
- you can also reproduce this bug by downloading a latest-trunk build and
forcing a check for software updates.
- I haven't seen the software update announce an available update without being
forced to check, but I haven't really let Deer Park run for any serious length
of time

(confirmed by mcsmurf in #developers)

Comment 1

[Frank Wein [:mcsmurf]]

The problem is probably this:
<updates>
<update type="minor" version="1.0+" extensionVersion="1.0+">
    </update>
</updates>

The server sends an empty update, so FF thinks there is a update. I think we
should fix the server ;)

Comment 2

[Chase Phillips]

Need to get verification on what the client interprets as "no updates available"
and change server output to that.  Darin will provide info on what the client
expects to see in that case.

Comment 3

[Darin Fisher]

I believe that the correct server response is an XML file containing just an
empty updates tag: <updates/>

It gets confused when <update> elements appear with missing attributes.

Comment 4

[Darin Fisher]

-> chase for server side changes

Comment 5

[Michael Morgan [:morgamic]]

https://aus-staging.mozilla.org:8711/update2/0/Firefox/1.0.4/2005070505/Linux_x86-gcc3/en-US/update.xml

An incorrect assumption was made about the update block -- now an empty update
does not show any update block unless the patch information is available.  Does
that work properly?

Comment 6

[Asa Dotzler [:asa]]

It seems that updating when you already have the latest now gives a 404 error.

Comment 7

[Michael Morgan [:morgamic]]

I've tested different combinations and as far as I can tell, if Software Update
sees:

<?xml version="1.0"?>
<updates>
</updates>

Firefox intereprets that as a 404 error instead of "There are no updates available".

So my question then becomes -- what output should AUS give in update.xml that
signifies to the client that an update is not available?

Comment 8

[Michael Morgan [:morgamic]]

(In reply to comment #7)
> <?xml version="1.0"?>
> <updates>
> </updates>
> 
> Firefox intereprets that as a 404 error instead of "There are no updates
available".

Note that <updates/> and a blank XML document also caused 404 errors in the user
interface.

Comment 9

[Zach Lipton [:zach]]

It's not a problem of update.xml needing to give different output to indicate
that no updates are available, it's that the updater itself fails to have any
provision for dealing with the fact that no updates may be available. See
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1530.

Comment 10

[Benjamin Smedberg]

Zach, unless I'm reading the code wrong
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1523
should return an empty array without throwing, from
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1497

Comment 11

[Darin Fisher]

-> over to me for client side investigation.  i think we are happy with what AUS
is currently outputing in this case.  thanks mike!

Comment 12

[Darin Fisher]

Attachment: v1 patch

Comment 13

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

Comment on attachment 188444 [details] [diff] [review]
v1 patch

r=[e-mail]

Comment 14

[Darin Fisher]

fixed-on-trunk