Closed Bug 471889 Opened 16 years ago Closed 14 years ago

Software update sometimes stops with "Update XML file malformed (200)" (Error: channel.securityInfo is null)

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.9.0 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.3a5
Tracking Flags:
Tracking Status
status1.9.2 --- .9-fixed

People

(Reporter: whimboo, Assigned: robert.strong.bugs)

References

Details

(Keywords: verified1.9.2, Whiteboard: [mozmill-test-needed]) 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090101 Minefield/3.2a1pre ID:20090101020547

Sometimes when doing a manual check the automatic update is aborted with the message "Update XML file malformed (200)". I have to start the manual check for several times until it works and gives me the update panel. This bug is filed against trunk but I can also see such a behavior on the 1.9.1 branch.

I've enabled the logging for the updater and following entries are shown inside the Error Console:

AUS:SVC General:getLocale - getting locale from file: /Applications/Minefield.app/Contents/MacOS/updater.ini, locale: en-US

AUS:SVC Checker:getUpdateURL - update URL: https://aus2.mozilla.org/update/3/Firefox/3.2a1pre/20090101020547/Darwin_Universal-gcc3/en-US/nightly/Darwin%209.6.0/default/default/update.xml?force=1

AUS:SVC Checker:checkForUpdates - sending request to: https://aus2.mozilla.org/update/3/Firefox/3.2a1pre/20090101020547/Darwin_Universal-gcc3/en-US/nightly/Darwin%209.6.0/default/default/update.xml?force=1

Error: channel.securityInfo is null
Source File: file:///Applications/Minefield.app/Contents/MacOS/components/nsUpdateService.js
Line: 103

AUS:SVC Checker:onError - request.status: 2153185313

AUS:SVC General:getStatusTextFromCode - transfer error: Update XML file malformed (200), default code: 200

AUS:SVC UpdateService:removeDownloadListener - no downloader!

The active-update.xml is not updated at this stage.
OS: Mac OS X → All
Hardware: x86 → All
I am a little confused here. When I read your bug description, it sounds like you say that an error occurs when no error should occur. But then you mark Bug 440750 as a duplicate. Bug 440750 is about when an error SHOULD occur, then the displayed message should describe the error that occurred and not another error. Can you clarify for me what this bug is about?
You are right, Jesper. While your bug will add a proper error message, this one is about the failure, which has to be fixed and also give a meaningful description.

I don't know if we can combine both bugs to solve the issues in one step. Robert, what do you think? Shall we reopen bug 440750 and mark it as blocking this bug?
I've already had my eye on bug 440750 along with this bug and would like to keep them separate since I don't know yet what is causing securityInfo to be null... as for dependencies I'd like to use this bug for securityInfo being null and bug 440750 for the error message in which case there is no dependency.
Just a note. I can see this bug too while using the betatest channel for release testing of Firefox 3.0.6. Each first manual check stops with this error message. A second try succeeded.
Version: 1.9.1 Branch → 1.9.0 Branch
That would imply that this isn't due to the large changes I made in bug 324121. It would be good to know if this can be reproduced when going from 2.0.0.x to 3.0.x especially when if it could be tested using the betachannel and the actual release channel since there might be a difference in the way the billboard is served up that is causing this.
Ok, here the info. I'm using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 for testing purposes.

I've tried with release and beta channel but both are running into the same issue. The error message is identical for 2.0.0.20.

But what I can see now, it could be somehow related to an installed extension. It's not reproducible for a clean profile. I'll step through the list of add-ons now to find the cause.
There is no add-on involved here but a pref which is causing this issue. I'll give all the information when I was able to narrow it down.
This bug happens due to the "Auto-detect proxy settings for this network" setting. When I switch to no proxy, everything is fine while having auto-detect mostly fails.
Are you using a proxy when this happens as well?
No, I don't use. I've even no idea why or when this setting was set. But as long as it hasn't failed each time, it was no question for me that something could be wrong with the network settings. Now it looks like that this setting isn't really trustful.
I asked because I wasn't able to reproduce when testing with it set. I'll leave it set and try again with tomorrows nightly.
I was able to reproduce using a Minefield build instead of Shiretoko. Interestingly enough, using my own server I wasn't able to reproduce at all (cleared the cache, exited, etc.).

Chances are this is a networking bug.
or perhaps an XHR bug
ccing sicking to hopefully figure out what is going on here
cc'ing Mossop to give him a heads up since this also affects add-on update checks... from the error console

Error: channel.securityInfo is null
Source File: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsExtensionManager.js
Line: 165

RDFItemUpdater:onError: There was an error loading the 
the update datasource for item inspector@mozilla.org, error: nsIXMLHttpRequest channel unavailable

Datasource: Addon Update Ended: inspector@mozilla.org, status: 4
(In reply to comment #16)
> cc'ing Mossop to give him a heads up since this also affects add-on update
> checks... from the error console
> 
> Error: channel.securityInfo is null
> Source File:
> file:///C:/Program%20Files/Mozilla%20Firefox/components/nsExtensionManager.js
> Line: 165

That error is expected in the case that the initial update request is to a https server but is then redirected to http. Has anyone reproduced with something like tamperdata installed to see if the request is getting redirected for some reason?
What type of XHR request are you doing? I'm guessing it's a GET request to some url?

I did recently fix a problem that related to proxy code and XHR (bug 464954), however that shouldn't have affected GET requests, and also shouldn't have affected requests coming from chrome.
I'm seeing this when using a proxy-server setting with a PAC file (auto-detect, system, automatic, ...), even though no proxyserver is actually present (I'm using a PAC file, but that's only accessible in the office, and will fail at home).

The workaround is to check for updates TWICE, since the first time will always fail, but the next ones will work (the failure is remembered apparently). But that doesn't help for the manual proxy-server settings, since that will fail every time.
Depends on: 569648
Fixed on trunk by bug 569648

Henrik, there is no way to write a test for this (details why are in bug 569648)... can you create a litmus test for this? Thanks
Assignee: nobody → robert.bugzilla
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
(In reply to comment #22)
> Henrik, there is no way to write a test for this (details why are in bug
> 569648)... can you create a litmus test for this? Thanks

Rob, the software update subgroup is under Al's hat. I would like to let him add the test. But I would feel happy to add a Mozmill restart-test later on. Are there changes to get this landed on older branches too?
Whiteboard: [mozmill-test-needed]
I'll request approval for bug 569648 on branches after bug 569648 has baked for a bit.

Al, could you please add a litmus test for this?
Sure, I can do that. The manual repro case is to do a check for update when Firefox is setup to auto-detect a proxy and none is present?
Yes with the addition that the homepage should be about:blank and no pages opened after open Firefox. Thanks
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100606 Minefield/3.7a5pre

Now that bug 569648 is checked in, I'm not seeing the behavior from comment 21 anymore. I used to see that daily.
Verified fixed with builds on Windows and OS X like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100605 Minefield/3.7a5pre
Status: RESOLVED → VERIFIED
(In reply to comment #23)
> (In reply to comment #22)
> > Henrik, there is no way to write a test for this (details why are in bug
> > 569648)... can you create a litmus test for this? Thanks
> 
> Rob, the software update subgroup is under Al's hat. I would like to let him
> add the test. But I would feel happy to add a Mozmill restart-test later on.
> Are there changes to get this landed on older branches too?
Would be a good thing to add a mozmill-restart test for this. All it would have to do is.
1. Launch and set home page to about:blank, don't restore tabs, and auto-detect for the proxy.
2. Restart and then check for updates.
(In reply to comment #29)
> Would be a good thing to add a mozmill-restart test for this. All it would have
> to do is.
> 1. Launch and set home page to about:blank, don't restore tabs, and auto-detect
> for the proxy.
> 2. Restart and then check for updates.

We cover the Mozmill test creation on bug 584002 now, fully independently if we will have a Litmus test or not.
Blocks: 584002
Fixed on 1.9.2 for Firefox 3.6.9 by bug 569648
status1.9.2: --- → .9-fixed
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10pre) Gecko/20100825 Namoroka/3.6.10pre
Keywords: verified1.9.2
Al, the Mozmill test has been landed. So whenever you add the Litmus test please reference the Mozmill test from bug 584002. Thanks.
(In reply to comment #33)
> Al, the Mozmill test has been landed. So whenever you add the Litmus test
> please reference the Mozmill test from bug 584002. Thanks.

Al, any chance you can add this Litmus test, so I can link the Mozmill test?
Sure, I'll make a note to do it in the next couple of days. This just fell out of sight. My apologies.
Added testcase 15083 for 3.6 and 15084 for 4.0.
(In reply to comment #36)
> Added testcase 15083 for 3.6 and 15084 for 4.0.

Any reason why those tests have been marked for Windows only? I have updated them to expand to all platforms and also added the references for the existing Mozmill tests.
My understanding was that the issue in question was only found on Windows, which is why I marked them.
Marking in litmus per comment #36
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.