Open Bug 774600 Opened 9 years ago Updated 2 years ago

xmlhttprequest gets completed handler when navigating away from page


(Core :: DOM: Core & HTML, defect, P5)

12 Branch





(Reporter: spamfaenger, Unassigned)


User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Steps to reproduce:

I've got an xmlhttprequest running to download some json from the server.

Said server is answering with a 304 not modified (etags are used) while the browser at the same time is navigating to a different page (user clicked a link).

Actual results:

This for me leads to the race condition that sometimes the xmlhttprequest gets set to ready state: 4 with response code 200 WITHOUT any of the expected content - even though the browser had it cached.

In my application this leads to an alert being shown, because the application thinks that the server has answered nonsensical (successful responses by the servers _have_ to include some valid json). This is unfortunate as this dialog is then shown on the next page and the user has no idea what to do.

Expected results:

Now I'm not really sure what the bug is here.

It could be that the request is marked as completed, even though it is really aborted (due to the user triggering the navigation to a different page).

It could also be that the bug is the browser erring in faking the 200 reply without correctly getting the data out of it's own cache.

Either way it would probably fix the issue for me - though it seems a bit more logical to just abort the request correctly in all cases instead of triying to execute some js while navigating away from the page (which should be the priority anyway, and the js is anyway halted at a random point in it's execution when the data for the new page comes in).

As it stands now, I'm somewhat at a loss as to how to work around this issue.
Component: Untriaged → DOM: Mozilla Extensions
Product: Firefox → Core
> ready state: 4 with response code 200

That's pretty odd, if the network request actually gets canceled.  There's certainly logic that makes canceled requests return 0 from .status....

Is there a public testcase that shows the problem, by any chance?
Sorry, no dedicated test case. My app shows this behavior - however it is quite hard to trigger this race condition by hand. 

The best I managed was with a selenium test case, that tests the admin part of it, which would trigger the bug in around 1 of 3 runs through the application - however at different spots and quite unpredictable. My evidence comes from printfs in the js that shows me that it really does give the 200 response with an empty json (empty string) while I can check from the server logs that it really does return 304.

In my own attempts to reduce this I have never been able to get this race condition to come up outside of this reproduction path. :-(

Moreover, having Firebug loaded seemed to cause enough delay that the bug never showed up. :-(
Component: DOM: Mozilla Extensions → DOM

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.