This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XHR should define unloading document cleanup steps ( http://www.whatwg.org/specs/web-apps/current-work/complete/history.html#unloading-document-cleanup-steps ) if there are open XHRs, close them and make the document unsalvageable
This specification defines the following unloading document cleanup steps. Make disappear any XMLHttpRequest objects that were created by the XMLHttpRequest() constructor or AnonXMLHttpRequest() constructor whose global object is the Document's Window object. If this affected any XMLHttpRequest objects, the set Document's salvageable state to false. If a user agent is to make disappear an XMLHttpRequest object (this happens when a Document object goes away), the user agent must follow the first appropriate set of steps from the following list: ↪If the XMLHttpRequest object is in the OPENED state with the send() flag being true, or the HEADERS_RECEIVED state, or the LOADING state Act as if the user aborted the cancels the request. ↪Otherwise Do nothing.
possibly you need to have a way to kill an XHR without firing events, to use when navigating away
So why exactly is this not needed for EventSource?
This is only needed for WebSocket apparently. For HTTP you can just kill the connection.
Per Anne's comment above no spec change is required.
Are you sure? I'm not a 100% sure. We have a way to terminate without events now so we might want to mention that it should be used here...
I'm not 100% sure either, but the referenced document unloading stuff was pretty specific to WebSocket in the details. We probably want to consult some developers and ask if there's anything we need to say here.
Let's leave this open until what needs to happen is decided on.
Looks similar to bug 23878 which I just assigned to Ian. Going to try that with this too.
I'm confused as to what you want me to do here. Can you elaborate?
Sorry, I meant to ask you to look at comment 0 and comment 1 to see if there's anything we need to define here.
Isn't this an XHR problem? I don't understand what you're asking me.
The main problem is that I'm not sure what to do. Whether this is applicable to XMLHttpRequest or not. If this is just about closing the connection, then I think we have that other bug for that about terminating all fetches associated with an environment.
You also need to make the document unsalvageable if it closed the connection. IIRC some browsers did this when I filed the bug, but maybe we should check what browsers do today...
"unsalvageable" is only mentioned in informative text in HTML. And does not include other elements that do fetching. I take it XMLHttpRequest is special in that regard when you tested it?
Created attachment 1524 [details] Demo unloading document, no XHR
Created attachment 1525 [details] Demo unloading document, with XHR
The normative bit is https://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:concept-document-salvageable-8
https://simon.html5.org/dump/unload-baseline.html https://simon.html5.org/dump/unload-xhr.html Given these, it seems there is no difference when using XMLHttpRequest.
I'm sending this back to XHR for now since I don't really understand what I'm supposed to do here, but please don't hesitate to send it back to me if there's something I should be doing. Thanks!
http://krijnhoetmer.nl/irc-logs/whatwg/20141016#l-568
Demos still work for me.