Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Right now it doesn't handle all the abort/cancelation/dispose scenarios. Work in progress ... stay tuned :-D

I tested with Chrome, Edge and Firefox locally.

Why does this PR remove Add/RemoveEventListener?

Why does this PR remove Add/RemoveEventListener?

Because we don't need it anymore. Do you think that it should be part of the public API going forward ?

The implementation in the PR right now is running unit test suite 5x slower than main branch. It's caused by blocking send operation until the buffer is empty.

We had chat with @kg and here are conclusions

• we would not block send operation's Task if the bufferedAmount is under 64k. This would improve throughput nearly to previous implementation and also apply backpressure for apps sending large data.
• we would keep the Add/RemoveEventListener code
• we would not automatically send 'close' to the server on operation cancelation. But we should allow the user to use CloseAsync after any cancelation.

Edit: this is all done now

Test failures are unrelated

Notes I made during code walkthrough with @CarnaViire

• OutOfMemory exception, it should not be translated as WebSocketException
• order of response ints[] on receive, name the index constants
• rename promise_control for open
• ws[BINDING.wasm_ws_pending_receive_promise_queue].drain -> int[]
• fixed GC root for middle of array, use ArraySegment and offset instead
• _mono_wasm_web_socket_send_buffering message_ptr-> message_root
• utf8 test outerloop on coreCLR
• bufferedAmount: "This value does not reset to zero when the connection is closed" what about CloseSent ?
• assert: when we get message and the receivers queue is not empty, there need to be empty even queue,
• assert: mirror of above in the receiver method
• code 1000 on abort https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent/code
  • 1005/1006 "is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint." RFC6455
  • Chrome exception on using 1001: "The code must be either 1000, or between 3000 and 4999", same for no (optional) code
• SendReceive_VaryingLengthBuffers_Success - no change for CoreCLR, keep the active issue for why it's so slow

Follow up on yesterday conversation with @CarnaViire about CloseOutput from client side.
There is no such API on browser WS.
And therefore we call WebSocket.close() instead.
Chrome immediately issues 'close' event and it would not call and any 'message' callbacks after that, even if there were some messages in flight from the server.

So, we are losing the messages from server after CloseOutputAsync, as compared to managed/desktop implementation which delivers them.

The alternative is to not call WebSocket.close() when CloseOutputAsync, but that seems even worse.

Follow up on yesterday conversation with @CarnaViire about CloseOutput from client side.
There is no such API on browser WS.
And therefore we call WebSocket.close() instead.
Chrome immediately issues 'close' event and it would not call and any 'message' callbacks after that, even if there were some messages in flight from the server.

So, we are losing the messages from server after CloseOutputAsync, as compared to managed/desktop implementation which delivers them.

The alternative is to not call WebSocket.close() when CloseOutputAsync, but that seems even worse.

Hm, this is a huge failure on browser vendors' part. I don't like the data loss here. Is there some way we could signal this behavior difference to the developer?

The other differences in behavior are

• we are not streaming partial messages, we delay them till endOfMessage.
• we are sending close(1000) NormalClosure on Abort()

Is there some way we could signal this behavior difference to the developer?

We agreed with @kg to issue warning into console once per app lifetime.
WARNING: Web browsers do not support closing the output side of a WebSocket. CloseOutputAsync has closed the socket and discarded any incoming messages.