WebSocket.onclose是否由用户导航或刷新触发？ [英] Should WebSocket.onclose be triggered by user navigation or refresh?

问题描述

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

I'm seeing some inconsistent browser behaviour between Firefox and Chrome in relation to the onclose handler being called.

似乎Chrome不会触发 onclose 用户页面导航/刷新。但是，Firefox确实触发了 onclose 。

It seems that Chrome does not trigger an onclose if it was caused by a user page navigation/refresh. However, Firefox does trigger the onclose.

在我看来，Firefox可能在这里正常运行： p>

It seems to me that Firefox may be behaving correctly here:

当WebSocket连接关闭时，可能干净，用户代理必须创建一个使用CloseEvent接口的事件，事件名称为close没有气泡，不可取消，没有默认动作，其isClean属性设置为true，如果连接关闭干净，否则为false，其代码属性设置为WebSocket连接关闭代码，其reason属性设置为WebSocket联系紧密的原因;并排队一个任务，首先将readyState属性的值更改为CLOSED（3），然后在WebSocket对象上调度事件。

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

即使可以导致一些偷偷摸摸的代码/意外行为。

任何人都可以确认预期的行为？

Can anybody confirm the expected behaviour?

如果你有一个库为用户自动重新连接如何知道您应该尝试重新连接？是否查看 CloseEvent .wasClean 财产？我必须假设干净意味着关闭应该是通过API调用 WebSocket.close（）或发送关闭框架的服务器发生的？如果网络错误导致关闭，我猜猜 wasClean 将是 false ？

If you have a library that auto-reconnects for the user how do you know if you should try to reconnect? Do you check the CloseEvent.wasClean property? I'm having to assume that 'clean' means that the close was supposed to happen through either an API call to WebSocket.close() or the server sending a close frame? If a network error causes the close I'm guessing the wasClean would be false?

在Pusher JavaScript库中，我们假定（onclose - >等待 - >连接）闭合应触发重新连接，除非我们处于关闭状态 - 开发人员已选择关闭连接。看来，socket.io客户端库做出相同的假设。

In the Pusher JavaScript library we assumed (onclose -> waiting -> connecting) that a close should trigger a reconnect unless we are in a closing state - the developer has chosen to close the connection. It would appear that the socket.io client library makes the same assumption.

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

Based on this the Firefox onclose event caused by user navigation/refresh triggers an unwanted reconnection because neither library check the CloseEvent.wasClean property.

以下示例可用于演示不一致：
http://jsbin.com / awonod / 7

Here's an example that you can use to demonstrate the inconsistency: http://jsbin.com/awonod/7

以下是我演示此问题的视频：
http://www.screenr.com/vHn8
（迟到了，忽略了几个滑倒：））

Here's a video of me demonstrating the problem: http://www.screenr.com/vHn8 (it's late, ignore the couple of slip-ups :))

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

One point to note is that my hitting the Escape key could also be causing the WebSocket connection to close. However, if you watch closely or try for yourself you will see the close event being logged just before the page refreshes.

推荐答案

意外的行为是由于Firefox和Chrome处理关闭Websocket的方式。当页面刷新时，两个浏览器都会关闭连接，但是Firefox将执行您的onclose代码，而chrome会关闭连接并直接跳过以重新加载新页面。所以是的，我确认这个奇怪的行为。

即使是陌生人，事实上，从我的观察中，在chrome中调用websocket.close（）将立即关闭连接并调用onclose函数，而Firefox等待从服务器返回的关闭消息。


如果从服务器收到关闭消息，wasClean属性将为true


如果您的库在不检查wasClean属性的情况下自动重新连接，那么这可能导致问题，因为它会在页面刷新时尝试重新建立连接。您应该考虑不要使用库来手动进行，它不应该很难，只需在onclose函数中使用if语句调用connect，确保onclean属性为true。或者要更安全地设置onbeforeunload中的变量，以防止任何新的连接。

The unexpected behavior is due to the way in which Firefox and Chrome handle the closing of a Websocket. When the page is refreshed, both browsers close the connection, however, Firefox will execute your onclose code, while chrome closes the connection and skips straight to re-loading the new page. So yes, I confirm this strange behavior.
Even stranger is the fact that, from my observations, calling websocket.close() in chrome will immediately close the connection and call the onclose function, while Firefox waits for a close message back from the server.

The wasClean property will be true if a close message was received from the server

If your library is auto-reconnecting without checking the wasClean property then this could cause a problem, as it tries to re-establish the connection as the page refreshes. You should consider not using the library for this and doing it manually, it should'nt be very hard, just call connect in the onclose function with an if statement making sure the onclean property is true. Or to be even more safe set a variable in onbeforeunload that prevents any new connection.

希望这有帮助！

这篇关于WebSocket.onclose是否由用户导航或刷新触发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！