12837 2011-05-31 23:11:52 +0000 Define unloading document cleanup steps 2016-08-12 08:53:35 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC Windows 3.1 RESOLVED WORKSFORME P2 normal --- 1 zcorpan annevk annevk hsteen ian mike public-webapps public-webapps-bugzilla oldest_to_newest 48983 0 zcorpan 2011-05-31 23:11:52 +0000 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 55293 1 zcorpan 2011-08-17 12:21:00 +0000 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. 55294 2 zcorpan 2011-08-17 12:25:33 +0000 possibly you need to have a way to kill an XHR without firing events, to use when navigating away 55312 3 annevk 2011-08-17 15:58:28 +0000 So why exactly is this not needed for EventSource? 55370 4 annevk 2011-08-17 22:51:09 +0000 This is only needed for WebSocket apparently. For HTTP you can just kill the connection. 95942 5 hsteen 2013-11-07 13:44:48 +0000 Per Anne's comment above no spec change is required. 95943 6 annevk 2013-11-07 13:49:41 +0000 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... 95945 7 hsteen 2013-11-07 14:15:00 +0000 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. 95952 8 annevk 2013-11-07 14:32:20 +0000 Let's leave this open until what needs to happen is decided on. 106573 9 annevk 2014-05-21 14:31:49 +0000 Looks similar to bug 23878 which I just assigned to Ian. Going to try that with this too. 112423 10 ian 2014-09-29 21:21:27 +0000 I'm confused as to what you want me to do here. Can you elaborate? 113176 11 annevk 2014-10-15 08:13:52 +0000 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. 113238 12 ian 2014-10-15 19:05:38 +0000 Isn't this an XHR problem? I don't understand what you're asking me. 113279 13 annevk 2014-10-16 08:01:44 +0000 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. 113282 14 zcorpan 2014-10-16 09:01:35 +0000 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... 113285 15 annevk 2014-10-16 09:49:43 +0000 "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? 113289 16 1524 zcorpan 2014-10-16 10:22:53 +0000 Created attachment 1524 Demo unloading document, no XHR 113290 17 1525 zcorpan 2014-10-16 10:23:27 +0000 Created attachment 1525 Demo unloading document, with XHR 113292 18 zcorpan 2014-10-16 10:31:26 +0000 The normative bit is https://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:concept-document-salvageable-8 113295 19 annevk 2014-10-16 11:31:30 +0000 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. 115558 20 ian 2014-11-26 20:05:39 +0000 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! 115610 21 zcorpan 2014-11-27 10:22:18 +0000 http://krijnhoetmer.nl/irc-logs/whatwg/20141016#l-568 127132 22 annevk 2016-08-12 08:53:35 +0000 Demos still work for me. 1524 2014-10-16 10:22:53 +0000 2014-10-16 10:22:53 +0000 Demo unloading document, no XHR unload-baseline.html text/html 448 zcorpan PCFkb2N0eXBlIGh0bWw+CjEKPGEgaHJlZj0nZGF0YTp0ZXh0L2h0bWwsPHNjcmlwdD5zZXRUaW1l b3V0KGZ1bmN0aW9uKCkgeyBoaXN0b3J5LmJhY2soKTsgfSwgMTAwMCk7PC9zY3JpcHQ+Mic+PC9h Pgo8c2NyaXB0PgpmdW5jdGlvbiBjbGVhbnVwKCkgewogIGRlbGV0ZSBzZXNzaW9uU3RvcmFnZS5m b287Cn0KaWYgKHNlc3Npb25TdG9yYWdlLmZvbykgewogIGNsZWFudXAoKTsKICBhbGVydCgiRG9j dW1lbnQgd2FzIHJlcGFyc2VkIik7Cn0gZWxzZSB7CiAgc2Vzc2lvblN0b3JhZ2UuZm9vID0gImZv byI7CiAgc2V0VGltZW91dChmdW5jdGlvbigpIHsgZG9jdW1lbnQubGlua3NbMF0uY2xpY2soKTsg fSwgMTAwMCk7CiAgc2V0VGltZW91dChmdW5jdGlvbigpIHsKICAgIGNsZWFudXAoKTsKICAgIGFs ZXJ0KCJEb2N1bWVudCBzdXJ2aXZlZCIpCiAgfSwgMzAwMCk7Cn0KPC9zY3JpcHQ+Cg== 1525 2014-10-16 10:23:27 +0000 2014-10-16 10:23:27 +0000 Demo unloading document, with XHR unload-xhr.html text/html 576 zcorpan PCFkb2N0eXBlIGh0bWw+CjEKPGEgaHJlZj0nZGF0YTp0ZXh0L2h0bWwsPHNjcmlwdD5zZXRUaW1l b3V0KGZ1bmN0aW9uKCkgeyBoaXN0b3J5LmJhY2soKTsgfSwgMTAwMCk7PC9zY3JpcHQ+Mic+PC9h Pgo8c2NyaXB0PgpmdW5jdGlvbiBjbGVhbnVwKCkgewogIGRlbGV0ZSBzZXNzaW9uU3RvcmFnZS5m b287Cn0KaWYgKHNlc3Npb25TdG9yYWdlLmZvbykgewogIGNsZWFudXAoKTsKICBhbGVydCgiRG9j dW1lbnQgd2FzIHJlcGFyc2VkIik7Cn0gZWxzZSB7CiAgc2Vzc2lvblN0b3JhZ2UuZm9vID0gImZv byI7CiAgdmFyIHhociA9IG5ldyBYTUxIdHRwUmVxdWVzdCgpOwogIHhoci5vcGVuKCdHRVQnLCAn aHR0cDovL3czYy10ZXN0Lm9yZy9pbWFnZXMvZ3JlZW4tMXgxLnBuZz9waXBlPXRyaWNrbGUoZDMp Jyk7CiAgeGhyLnNlbmQoKTsKICBzZXRUaW1lb3V0KGZ1bmN0aW9uKCkgeyBkb2N1bWVudC5saW5r c1swXS5jbGljaygpOyB9LCAxMDAwKTsKICBzZXRUaW1lb3V0KGZ1bmN0aW9uKCkgewogICAgY2xl YW51cCgpOwogICAgYWxlcnQoIkRvY3VtZW50IHN1cnZpdmVkIikKICB9LCAzMDAwKTsKfQo8L3Nj cmlwdD4K