This may not be the answer you want, but ...
Most of the production environments for websocket applications work behind the Websocket proxy (Apache, Nginx, etc.), which usually also act as a load balancer.
These servers will also use the timeout mechanism, which is necessary to avoid half closed sockets (when only one side has closed the connection and no data is transmitted, an error does not occur, and the file descriptor may remain open indefinitely).
For example, Heroku provides a 55 second timeout .
This means that you should probably set your heartbeat anyway - even if your development application is not experiencing a shutdown.
If you are writing a server-side application and have control over the websocket, you should probably configure ping frames that will not onmessage event (ping and pong frames have different op code and are not part of a regular message sequence).
Some websocket frameworks (such as Plezi on Ruby) will automatically configure pinging as the default setting, but some servers / frameworks leave this for you.
Summarizing:
These outages will be the expected behavior (even the required behavior) for the production environment . Although this is also likely to be an MS Edge issue, you may have to run out in both cases.
PS
The Websocket standard states that:
Servers MAY close the WebSocket connection as needed. Clients SHOULD NOT close the WebSocket connection arbitrarily.
Servers (and Websocket proxies and load balancers) use this to set their timeouts. Customer Responsibility for Reconnecting .
MS Edge really should not use a timeout, since this is not the expected behavior according to the standard ... although Edge can do this to make sure the connection is still open (forcing the script to reconnect as a reaction to an arbitrary server shutdown).