event-handling - WebSocket.onclose应该由用户导航或刷新触发吗？

Question

第1部分:预期的行为？

我发现Firefox和Chrome之间的浏览器行为与被调用的onclose处理程序不一致。

如果Chrome是由用户页面导航/刷新引起的，则Chrome似乎不会触发onclose。但是，Firefox会触发onclose。

在我看来，Firefox在这里的行为可能正确:

When the WebSocket connection is closed, possibly cleanly, the user agent must create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is set to true if the connection closed cleanly and false otherwise, whose code attribute is set to the WebSocket connection close code, and whose reason attribute is set to the WebSocket connection close reason; and queue a task to first change the readyState attribute's value to CLOSED (3), and then dispatch the event at the WebSocket object.

资料来源: http://www.w3.org/TR/2011/WD-websockets-20110419/#closeWebSocket

即使它可以导致一些 sneaky code/unexpected behaviour。

有人可以确认预期的行为吗？

第2部分:如何实现自动重新连接？

如果您有一个为用户自动重新连接的库，您如何知道是否应该尝试重新连接？您是否检查 CloseEvent.wasClean 属性？我必须假设“干净”意味着关闭应该通过对 WebSocket.close()的API调用或服务器发送关闭帧来发生？如果网络错误导致关闭，我猜 wasClean将是 false吗？

在Pusher JavaScript库中，我们假设(onclose->等待->连接)，除非我们处于关闭状态，否则关闭应该触发重新连接-开发人员选择关闭连接。似乎socket.io客户端库做出了相同的假设。

基于此，由用户导航/刷新引起的Firefox onclose事件会触发不必要的重新连接，因为这两个库都不检查 CloseEvent.wasClean属性。

示例和视频

这是您可以用来证明不一致的示例:
http://jsbin.com/awonod/7

这是我演示问题的视频:
http://www.screenr.com/vHn8
(太晚了，请忽略一些滑动:))

需要注意的一点是，我按下Escape键也可能导致WebSocket连接关闭。但是，如果您仔细观察或自己尝试，则会在页面刷新之前看到close事件正在记录。

Answer 1

意外行为是由于Firefox和Chrome处理Websocket关闭的方式所致。刷新页面后，两个浏览器都会关闭连接，但是Firefox将执行您的onclose代码，而chrome将关闭连接并直接跳过以重新加载新页面。是的，我确认了这种奇怪的行为。
甚至更奇怪的是，据我观察，在chrome中调用websocket.close()会立即关闭连接并调用onclose函数，而Firefox等待从服务器返回的关闭消息。
如果从服务器收到关闭消息，则wasClean属性将为true
如果您的库在不检查wasClean属性的情况下自动重新连接，则可能会导致问题，因为它会在页面刷新时尝试重新建立连接。您应该考虑不使用该库并手动执行该操作，这应该不会很困难，只需使用if语句在onclose函数中调用connect即可确保onclean属性为true。为了更加安全，请在onbeforeunload中设置一个变量，以防止任何新连接。

希望这可以帮助!