What should happen when the WebSocket constructor is called for a global whose document is not current?

[bzbarsky]

As far as I can tell, the spec requires that the constructor work and return a websocket, and this websocket try to connect and whatnot. But I don't see what would ever shut down that connection, once established. Websocket connections are normally shut down during navigation, but only the ones corresponding to the global being unloaded, and we're past that step for this global.

See http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4721 for a kinda testcase, though it's using a websocket to something that doesn't speak websocket, so doesn't actually end up with a connection.

In terms of UA behavior, Firefox throws from the constructor in this situation. Chrome creates the object, but it behaves in what look like spec-violating ways (e.g. transitions from the CONNECTING state to the CLOSED state without firing a "close" event as far as I can tell). I haven't tested other UAs, or what happens if the URL used points to an actual websocket endpoint.

[bzbarsky]

Note that it's not clear to me how consistently Firefox throws here. It does in this specific testcase, but I'm not sure it would if page being unloaded had gone into bfcache (which subframe navigations never do in Gecko).

[annevk]

I guess ideally we make this behave similar to what XMLHttpRequest does in https://xhr.spec.whatwg.org/#dom-xmlhttprequest-open, right? Would be good to have tests though.