XMLHTTPRequest Randomly Fails with Status Code 0 During Reload/Refresh and/or Multiple Requests

[Edwin Grubbs]

Binary package hint: mozilla-firefox

If Firefox 3.0 or 3.5 is making an XMLHTTPRequest, and the page load is interrupted, Firefox calls the failure handler with a response status of zero.

[E-grubbs (e-grubbs)]

I also experienced this problem in Firefox 3.0.11. It was easiest to trigger my making the server side respond really slowly and then hitting escape to stop loading the page.

[Edwin Grubbs (edwin-grubbs)]

Binary package hint: mozilla-firefox

If Firefox 3.0 or 3.5 is making an XMLHTTPRequest, and the page load is interrupted, Firefox calls the failure handler with a response status of zero.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

This is apparently not limited to OS X.
Ubuntu Bug from Edwin Grubbs (Comment #1):
https://bugs.launchpad.net/bugs/394912

He said this happened in Firefox 3.5 as well.

[Micah Gersten (micahg)]

Reporter already commented on Upstream bug.

[Kees Cook (kees)]

This is causing the LP Greasemonkey scripts to fail -- not only is status == 0, but the response is blank too (i.e. responseText is empty). Watching requests in TamperData shows status 200 with a size of "-1" ?!

[Olli-pettay (olli-pettay)]

I get similar behavior with Firefox, Safari and Chrome when testing
http://homepage.mac.com/zacware/firefox_bug/firefox_bug.htm
X number alerts.

The testcase is strange. It assumes that the next page can somehow access the
previous page.

[Olli-pettay (olli-pettay)]

And on FF2.0.0.x accessing XMLHttpRequest.status in the event listener gives NS_ERROR_NOT_AVAILABLE error.

My guess is that the page relied on unintended behavior.

[C de-Avillez (hggdh2)]

I can confirm on FFox 3.5.2, as packaged on Ubuntu Karmic. It does not happen always (in my case), and I have not yet determined why.

[Steve-weintraut (steve-weintraut)]

If it helps, here's a simpler example using jQuery that exhibits the same behavior as my original example.

http://homepage.mac.com/zacware/xhr_bug/xhr_bug.htm

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

This seems to have been caused by the patch for Bug 424212

Here is the changeset in mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/151522b6da28

[C de-Avillez (hggdh2)]

Hum. Looking at the FF console I see this error:

Error: [Exception... "update.locale file doesn't exist in either the XCurProcD or GreD directories" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: file:///usr/lib/xulrunner-1.9.1.2/components/nsUpdateService.js :: getLocale :: line 549" data: no]
Source File: file:///usr/lib/xulrunner-1.9.1.2/components/nsUpdateService.js
Line: 549

Obviously, this would be enough to have status=0 in my case. So *my* question now is where would this 'update.locale' file be? How can I recover it?

[C de-Avillez (hggdh2)]

No matter. What I found later on is even more interesting: if I go to edge.launchpad.net, I *usually* -- about 99 out of 100 -- get a status=0 response, with empty text.

Now, if I go to launchpad.net, I *never* get it -- meaning so far, none.

This is sounding more as a launchpad issue than anything else.

[C de-Avillez (hggdh2)]

Indeed. I just found that edge.launchpad.net is routing/presenting some HTTP requests to/as https://edge.lp.net, instead of the stable https://bugs.edge.lp.net. As a result, the GM scripts fail on a XSS (since we are running off https://bugs.edge.lp.net, and the request is sent over to https://edge.lp.net).

I have not looked at tamperdata output, but firebug shows a 200 status, while the event handler in JS shows a status == 0.

Going back to https://bugs.launchpad.net makes the scripts work. So. Something changed on Edge.

Can someone please confirm the above?

[C de-Avillez (hggdh2)]

I had a chat with wgrant:

<hggdh> wgrant, can you expand, please?
<hggdh> what I see is an error (encrypted), and a status==0. If I understand what is wrong, I may be able to correct it
<wgrant> hggdh: Person links recently had the "bugs." dropped from them. This is quite intentional. Your problem might be that the browser security is kicking in and refusing to let you make a cross-domain request.
<hggdh> wgrant, I am rather new to this(in fact, my very first JS script ever). How could I bypass the browser security?
<wgrant> hggdh: You can't. You have to make requests to the same domain.
<hggdh> so we are pretty much dead with the GM scripts against bugs.edge?
<wgrant> hggdh: What you could do is construct a relative URL. This probably means taking everything after the '~' from the person URL, and prepending '/~'.
<wgrant> hggdh: No, you just have to make the requests against bugs.edge.
<wgrant> hggdh: Link me to the script, and I will fix.
<wgrant> (some of LP's JS broke the same way, so I know how to fix)
<hggdh> cool!
<hggdh> https://code.edge.launchpad.net/~hggdh2/launchpad-gm-scripts/hggdh2
<hggdh> it's the lp_karma_suffix.user one
<hggdh> and, to boot, I will learn more!
<hggdh> I understood I could not change the host in a XMLHttpRequest...
<wgrant> hggdh: You just have to change the URL that you give it.
<wgrant> hggdh: Is that the canonical copy of that script?
<hggdh> wgrant, this is the change I proposed to add in the ability to follow a commeter's bug work (for bugs-control)
<hggdh> I do remember I *did* change the URL, and still got hit by the status=0 -- so I guess I did it wrong, out of the depths of my ignorance
<hggdh> wgrant, ping
<hggdh> wgrant, I think I got it. I changed the links as here: http://paste.ubuntu.com/262862/, and it is working now. I *guess* this is what you menat

For the record, this is how it got to work on lp_karma-suffix:

    if (!people_cache[person]) {
        people_cache[person] = new Array();
        // drop '//bugs.' from the link URL
// people_cache[person]['person_link'] = link.replace(/\/\/bugs\./, "//");
// GM_log ("add_people: person_link=" + people_cache [person]['person_link']);
        people_cache[person]['team_link'] = "~/" + link;
        people_cache[person]['person_name'] = node.text;
        people_cache[person]['karma_link'] = "~/" + link + "/@@+portlet-details";

In this example, link had, as value, "https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.0/+bug/394912/". After the assigment, karma_link got to be "https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.0/+bug/394912/~/https://edge.launchpad.net/~hggdh2/@@+portlet-details", which works perfectly.

So I expect the firefox tasks, both local and upstream, can be closed invalid, and we are only left with the launchpad GreaseMonkey Scripts to worry about.

Still to be tested: how will it behave on stable LP, as opposed to Edge.

[Kees Cook (kees)]

Agh! Yes, thank you for catching the domain name changes. I wouldn't have expecting a status==0 for that. I've updated the script to build the domain from document.location instead of the links in the HTML.

[Christian-pingroom (christian-pingroom)]

We have the same kind of problem in a XUL app, when some XMLHTTP requests are launched rapidly, we have "sometimes" an error.

Observing data with wireshark shows a [TCP Previous segment lost] and a [TCP Out-Of-Order] for the awaited response. Maybe it could help

[Nagle-animats (nagle-animats)]

I have this as well, on Firefox 3.5.3 under both Windows 2000 and Windows Vista.
I have an application that makes an XMLHttpRequest every 5 seconds. The page alternates between waiting for the 5-second timer callback and waiting for the XMLHttpRequest callback. When I leave the page by clicking on an image, the XMLHttpRequest callback is sometimes called with state=4, status=0.

The changeset at "http://hg.mozilla.org/mozilla-central/rev/151522b6da28" looks like it explains this situation.

[nikunjmulani (nmulani)]

Hi,
I am getting similar issue with firefox 3.5.3 (ubantu).

Please review following code

function onSubmitPage() {

          XMLHttpRequest req = new XMLHttpRequest();
          req.onreadystatechange = processStateChangeForElement;
          try {
               req.open("POST", url, true);
          } catch (e) {
          }

[Tyler Downer (tyler-downer)]

Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile (
http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available.

If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME

filter: prefirefox4uncobugs

[Edwin Grubbs (edwin-grubbs)]

I can verify that this is fixed in Firefox 4.0.1 on Ubuntu.

[Micah Gersten (micahg)]

Marking the Firefox task Fix Released since it's now fixed in Firefox 4

[Micah Gersten (micahg)]

Marking firefox-3.5 won't fix since Karmic is EOL

[Swarnava Sengupta (swarnavasengupta)]

looks like op is not here around, if you can reproduce, feel free to reopen it!

[Marcus-fritze (marcus-fritze)]

Ok it seems that this is still an issue in Firefox 25.0.1 (on OS X).

I am using https://github.com/PixelsCommander/OnlineJS which sends XMLHTTPRequests to a server to check if the server is online. Sometimes the return status is 0. About 5 of 100 request the status is 0.

Other browsers are working without any problems.

Maybe someone can confirm this issue.

[Swarnava Sengupta (swarnavasengupta)]

(In reply to Marcus Fritze from comment #12)
> Ok it seems that this is still an issue in Firefox 25.0.1 (on OS X).
>
> I am using https://github.com/PixelsCommander/OnlineJS which sends
> XMLHTTPRequests to a server to check if the server is online. Sometimes the
> return status is 0. About 5 of 100 request the status is 0.
>
> Other browsers are working without any problems.
>
> Maybe someone can confirm this issue.

hey Marcus, can you file a new bug with proper step to reproduce from here https://bugzilla.mozilla.org/enter_bug.cgi

[Marcus-fritze (marcus-fritze)]

Thanks for the quick response, I created a new issue: Bug 942942