Websockets are sometimes not closed on Window.unload

[Archmonger]

Description

Websockets are sometimes not cleanly terminated on window.unload, even if a specific event handler is registered to close() the websocket.

Steps to Reproduce

1. Create any test web development that has a websocket connection between the server and client
2. Open up the webpage in the client
3. Spam CTRL+R as fast as you can
4. Watch the Brave sometimes not terminate the websocket.
5. Unterminated WS will remain open until Keep-Alive timeout, causing WS from new tab loads to not connect.

Actual result:

WS can remain open on window.unload, even when explicitly closing it.

Expected result:

All websockets should cleanly terminate on browser unload.

Reproduces how often:

Easily reproduced.

Brave version (brave://version info)

Brave | 1.31.87 Chromium: 95.0.4638.54 (Official Build) (64-bit)
Revision | d31a821ec901f68d0d34ccdbaea45b4c86ce543e-refs/branch-heads/4638@{# 871}

Version/Channel Information:

• Can you reproduce this issue with the current release?
  Yes
• Can you reproduce this issue with the beta channel?
  Untested
• Can you reproduce this issue with the nightly channel?
  Untested

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields?
  No
• Does the issue resolve itself when disabling Brave Rewards?
  No
• Is the issue reproducible on the latest version of Chrome?
  No

Miscellaneous Information:

This issue is persistent on browser tab close.

I had attempted explicitly closing the websocket through registering a window.unload event handler, and this still didn't resolve the issue.

window.addEventListener("unload", function () {
	// Also tested with != Websocket.CLOSED
	if (COMMAND_SOCKET.readyState == WebSocket.OPEN) COMMAND_SOCKET.close();
});

This appears to already be resolved in Chrome, Opera, and FF.

[wanton7]

Sounds like this could be related to #15410

[Archmonger]

If it is, then that ticket has been categorized wrong. Also the name and description have characterized the issue wrong, at least from my testing.

[wanton7]

Yes it is categorized wrong. I don't understand why that has been labeled as repros-on-chrome & Chromium/waiting upstream. It was labeled by rebron because he thought it relates to some chromium issue. After that OP said it doesn't repro on Chrome #15410 (comment) but rebron didn't remove the label.