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

[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" !

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.

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

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

(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" ?

[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 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 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)?

(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 :-/

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

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

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

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

(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 ;)

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.

(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