13295 2011-07-19 05:20:40 +0000 The "make disappear a WebSocket object" case should not fail the WebSocket connection 2011-08-08 21:24:49 +0000 1 1 1 Unclassified WebAppsWG WebSocket API (editor: Ian Hickson) unspecified PC All RESOLVED WONTFIX P3 normal --- 1 brian.raymor ian ian jonas mike public-webapps public-webapps-bugzilla oldest_to_newest 51255 0 brian.raymor 2011-07-19 05:20:40 +0000 Are there valid use cases where the developer would want to capture this case as an error condition? If a user agent is to make disappear a WebSocket 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 WebSocket connection is not yet established [WSP] Fail the WebSocket connection. [WSP] 54263 1 ian 2011-08-05 23:05:42 +0000 I don't understand the question. What would you do instead? Let the handshake complete then close it? How would it be captured as an error condition? It's not like any events are going to be fired, the event queue is about to be torn down... 54276 2 brian.raymor 2011-08-06 00:13:38 +0000 If the connection is not established, then the preference is to treat this as a "user cancel" rather than an error and simply "close the websocket connection" and fire onClose. The other option is to be specific about the "fail the websocket connection" behavior for this case and indicate onError is not fired. Based on the definition of "fail the websocket connection" in the protocol draft, "report the problem to the user" is a MAY: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-7.1.7 Certain algorithms and specifications require an endpoint to _Fail the WebSocket Connection_. To do so, the client MUST _Close the WebSocket Connection_, and MAY report the problem to the user (which would be especially useful for developers) in an appropriate manner. 54404 3 ian 2011-08-08 21:24:49 +0000 By the time you are to "make disappear a WebSocket object", no events are going to fire ever again for that WebSocket object — the entire event queue for the Document is about to be cleared. So the only difference here is at the protocol level, and even there, there is essentially no difference — in fact the only difference is that "fail" says that the UA "may" report a problem, as you quote. But then the UA is always allowed to do that. That's just UI. So anyway, I don't understand what difference this would ever make. I've left the spec as is. The requirements on user agents are identical.