tyoshino@, yhirano@: Would y'all mind triaging this? Might be as trivial as dropping the check in `DOMWebSocket::connect()` (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/websockets/DOMWebSocket.cpp?rcl=da4b23b1d2a82705f7f4fdfb6c9c8de00341c0af&l=331)?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks like only Edge does what the test expects:

https://wpt.fyi/results/websockets/Create-blocked-port.any.html

 Issue 872252  has been merged into this issue.

Cool, here's a permalink showing Edge passing:
https://wpt.fyi/results/websockets/Create-blocked-port.any.html?sha=edb72456b7

My main concern is that we won't be able to test port blocking from JS any more. I think we will need a new unit test for net::WebSocketChannel to compensate.

It'll still be testable, it should just fire an error event instead of throwing an exception. That's how Edge passes the tests :)