Honza Bambas (:mayhemer) Reporter
	Description • 6 years ago

+++ This bug was initially created as a clone of Bug #1418134 +++

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38

Steps to reproduce:

Make some XMLHttpRequests, and then before receiving a response, navigate away by setting the window location.

Plnkr here to demonstrate (run it in a new window, and use preserve log in the devtools so that you can see the logs after the redirect has happened): https://plnkr.co/edit/10q3RE0cZwvzfckphnj8


Actual results:

The requests are cancelled, and the onerror callback and the onloadend callback are called on the XMLHttpRequest.


Expected results:

The requests should be cancelled, however Safari and Chrome on macOS don't call the onerror callback, they just call the onloadend callback. I believe this is the correct behaviour as onerror is reserved for low level network errors and this doesn't seem to fit the description. Plus, it is inconsistent with other browsers.

	Honza Bambas (:mayhemer) Reporter
	Comment 1 • 6 years ago

Daniel, can you please open this bug?  I made a clone of bug 1418134 and forgot to un-tick the Security-Sensitive Network Bug checkbox.  This is not a sec issue.  Thanks.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 6 years ago

Relevant bits that didn't get copied from bug 1418134:

The relevant spec bit is starting at https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents step 9 which calls into https://html.spec.whatwg.org/multipage/browsing-the-web.html#abort-a-document which does:

  Cancel any instances of the fetch algorithm in the context of document

Nothing defines what "cancel" means, here or in <https://fetch.spec.whatwg.org/>.  What Gecko does is return  a "network error" response in the sense of https://fetch.spec.whatwg.org/#concept-network-error and that of course triggers the "error" event on the XHR.  Since the behavior _does_ look like a network error from the point of view of the page (akin to a connection drop), this looks appropriate to me.

Anne says:

I think this is basically https://github.com/whatwg/html/issues/4007, ergo this requires tests, coordination with other browsers, and someone to come up with a plan for desirable behavior.

(As for intent, I think it's roughly what Firefox is doing, though perhaps with the "abort" event rather than "error", but that intent was from a time when investigations into behavior were far less thorough and understanding of abuse was more naïve. Not that I'd classify this as a security issue though.)

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 6 years ago

> I think this is basically https://github.com/whatwg/html/issues/4007

I don't think so.  The events in question are firing while the document is still active.

	Anne (:annevk)
	Comment 4 • 6 years ago

Apologies, though I think my "ergo" is still apt (i.e., this needs investigation), but I cannot find the canonical issue here (https://github.com/whatwg/html/issues/3837 seems related). Also, from what I recall browsers are not aligned on the quoted step above and some browsers terminate the fetches at a later stage at which point they do not update the document in question.

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 6 years ago

OK.  Given that, I don't think this should be P2 or major, since we're following the current spec here.  In particular, I don't think we should make changes here unless and until a different behavior is clearly agreed on in the spec.

	Honza Bambas (:mayhemer) Reporter
	Comment 6 • 6 years ago

P2 carried from the original bug.  P3 based on comment 5