407838 - Software Update 2nd step displays "Failed (Unknown Reason)" if working offline.

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[skierpage]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120915 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120915 Minefield/3.0b2pre

This is a variation of bug 312661, a different error message later in the update process.

If Firefox 3 (Minefield) has updated information about an update, and *then* you choose File > Work Offline, Help > Check for Updates reports "There were problems.... Failed (Unknown Reason)"

Reproducible: Sometimes

Steps to Reproduce:
1.  Let Firefox download information about an update, or choose Help > Check for Updates and then cancel before you download.
2.  Go offline with File > Work Offline
3.  Now choose Help > Check for Updates
Actual Results:  
The update dialog first reports
  An update for Minefield is available:

but when you click [Download & Install Now>>], you get:

  Completing the Software Update
  There were problems checking for, downloading, or installing this update.  Minefield could not be updated because:

  Failed (Unknown Reason)

Expected Results:  
The error message is confusing.
As in bug 312661, Check for Updates should alert with something like "You are working offline.  Uncheck "Work Offline" in the File menu, then try again."

This probably happens in Thunderbird as well.  It doesn't happen very often, I hope fixing bug 312661 takes care of this as well.  Maybe the toolkit should have a general "CheckForNetworkAccess()" step before it attempts network access, or better internal error propagation so it can report more known reasons why network access failed to the user.

Folks, DO NOT use this bug to report problems with Software Update, even if you see the same error message, unless you have chosen to WORK OFFLINE!  (Instead maybe bug 393778 is relevant.)

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012102 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Confirming:
1. Check > (find update) > Later.
2. Go offline.
3. Check > Download > "Unknown Reason" !

Comment 2

[Marcia Knous [:marcia]]

Testing this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre, I get AUS: Update XML File Malformed (200) as the Error Message, which is not great messaging.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)

Did you not rather want to post this comment in bug 312661 ?
The error text looks like it, and I wonder how you can get to step 2 as there shouldn't be an update available on the same day as the build...

Comment 4

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

After reading bug 393778 comment 3, I looked into it:

The code and strings:
<http://mxr.mozilla.org/seamonkey/search?string=checker_error-&case=on&tree=seamonkey>

In this bug, we get:
Actual code : 2152398918 (undefined string)
Default code: 2152398849 (= "Failed (Unknown Reason)")
from
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in&rev=1.150&mark=2574-2576#2564>

While it seems we would want to get
"2152398864 = Network is Offline (Go online)"
<http://mxr.mozilla.org/seamonkey/search?string=2152398864&case=on&tree=seamonkey>
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/base/public/nsNetError.h&rev=1.12&mark=184-189#183>

If I understand correctly, 2152398918 is "NS_ERROR_DOCUMENT_NOT_CACHED" at
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/base/public/nsNetError.h&rev=1.12&mark=332-337#331>

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #4)
> Actual code : 2152398918 (undefined string)
> If I understand correctly, 2152398918 is "NS_ERROR_DOCUMENT_NOT_CACHED" at

What is the wanted fix here ?
*Get the "offline" error code from the caller ?
*Add a string for the "not cached" error code ?
 *This string being a duplicate of the one for "2152398864" ?

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) <updates.properties> [Checkin: in bug 312661]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050303 Minefield/3.0pre] (FX-WIN32-TBOX-trunk) (W2Ksp4)

This patch fixes comment 4 and bug 312661 comment 32,
by adding
{{
# NS_ERROR_OFFLINE
[...]
# NS_ERROR_DOCUMENT_NOT_CACHED
checker_error-2152398918=Network is Offline (Go online)
}}

While we're there, it reorders the other errors by their codes.

Wrt comment 5, if you think that this is the proper fix, fine;
but, if you think that this is only wallpaper over an underlying network/cache issue,
then I think we should still take this in the meanwhile.

Comment 7

[Serge Gautherie (:sgautherie)]

Comment on attachment 319494 [details] [diff] [review]
(Av1) <updates.properties>
[Checkin: in bug 312661]

(In reply to comment #6)
> [...]
> While we're there, it reorders the other errors by their codes.

Moreover, should all the errors start with "AUS: " ?

Comment 8

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

Comment on attachment 319494 [details] [diff] [review]
(Av1) <updates.properties>
[Checkin: in bug 312661]

It is a tad late for localization changes in 1.9. How about checking the error code and then displaying the message for 2152398864 (e.g. NS_ERROR_OFFLINE)?

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> (From update of attachment 319494 [details] [diff] [review])
> It is a tad late for localization changes in 1.9. How about checking the error

Too late for this |late-l10n| candidate, which is a duplicated string only ?

> code and then displaying the message for 2152398864 (e.g. NS_ERROR_OFFLINE)?

Such a wallpaper could be (double-)added to |getStatusTextFromCode()|, yes.
Anyway, bug 312661 Av1 fix was |approval1.9-|, then I'll wait for this bug too :-/

Comment 10

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

(In reply to comment #9)
> (In reply to comment #8)
> > (From update of attachment 319494 [details] [diff] [review] [details])
> > It is a tad late for localization changes in 1.9. How about checking the error
> 
> Too late for this |late-l10n| candidate, which is a duplicated string only ?
Yes... it would require all locales to add this string and the l10n freeze has been in affect for quite some time.

Comment 11

[Samuel Sidler (old account; do not CC)]

Don't think we want an l10n change now. Let's get this in 1.9.1.

Comment 12

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

Comment on attachment 319494 [details] [diff] [review]
(Av1) <updates.properties>
[Checkin: in bug 312661]

We can take this on the trunk since l10n is not frozen. r=me

I'll land this as part of bug 312661

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> (From update of attachment 319494 [details] [diff] [review])
> We can take this on the trunk since l10n is not frozen. r=me

For 1.8.1 branch, I will (later) prepare a patch with your comment 8 suggestion.

> I'll land this as part of bug 312661

Go ahead.

Comment 14

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

(In reply to comment #13)
> (In reply to comment #12)
> > (From update of attachment 319494 [details] [diff] [review] [details])
> > We can take this on the trunk since l10n is not frozen. r=me
> 
> For 1.8.1 branch, I will (later) prepare a patch with your comment 8
> suggestion.
Thanks... btw: that would be for the cvs trunk which is 1.9.0.x... the hg trunk is 1.9.1.x... that's about as clear as mud ;)

Comment 15

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

Fixed by the checkin of bug 312661. Work to get this in for Firefox 3.0.x (e.g. 1.9.0.x) should be done in bug 312661 as well.

Comment 16

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

(In reply to comment #13)
> (In reply to comment #12)
> > (From update of attachment 319494 [details] [diff] [review] [details])
> > We can take this on the trunk since l10n is not frozen. r=me
> 
> For 1.8.1 branch, I will (later) prepare a patch with your comment 8
> suggestion.
I went ahead and added it to a 1.9.0.x patch in bug 451164

Adding dependency to bug 451164 for fixing this for 1.9.0.x