Investigate "salvageable" and WebSocket interaction

[zcorpan]

https://html.spec.whatwg.org/multipage/browsers.html#unloading-document-cleanup-steps

Make disappear any WebSocket objects that were created by the WebSocket() constructor from the Document's Window object.

If this affected any WebSocket objects, then set Document's salvageable state to false.

http://w3c-test.org/websockets/unload-a-document/001.html
expects the document to be discarded, and passes in Gecko/Chromium/WebKit.

http://w3c-test.org/websockets/unload-a-document/002.html
expects the document to not be discarded, and fails in Gecko/Chromium/WebKit.

Need to investigate what's going on here, and if the spec/test need changing...

[ricea]

It would be nice to change the behaviour so that more pages are salvageable. Specifically, if we fire onerror and onclose events when the page is restored from the back/forward cache, we should be able to achieve reasonable compatibility with existing pages while permitting increase use of the back/forward cache.

[zcorpan]

@ricea is the expectation that the vast majority of pages that use websockets will open a new websocket when the current one unexpectedly closes?

For pages that don't do so automatically, the user would have to either click a button (or so) in the page to open a new websocket, or reload the page. Similar to briefly losing network connection without navigating the page.

It seems OK to me to change so that websockets are always closed on navigation (and you get a close event on restore), but doesn't change "salvageable".

I don't think we should fire error as well as close -- currently the spec only fires one or the other, depending on whether the connection is already established.

[ricea]

I don't think we should fire error as well as close -- currently the spec only fires one or the other, depending on whether the connection is already established.

The spec always fires close after error: https://websockets.spec.whatwg.org/#closeWebSocket

In Chrome the error event means exactly "we are going to fire a close event with wasClean set to false immediately after this".

So the question comes down to "do we set wasClean to true or false when we close the WebSocket due to navigation?" I think setting it to false is more likely to get useful behaviour from existing pages, as they will recognise it as a connection error.