User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Steps to reproduce:

1. Go to this test site and press Connect.
2. Open Netmonitor > Click on request > Click on Messages panel.
3. Send the message via Send Blob/Send Array Buffer/Send ByteBuffer.

Actual results:

The payload is observed in the Messages panel as a String.

Expected results:

In nsIWebSocketListener.idl, the frame payload is defined to be of type ACString.

It would be nice if the payload returned is in the form of its corresponding binary type. This would support Bug 1555641 as DevTools can check the payload's binary type and parse its result correctly to the user.

Two thoughts here:

• Would this somehow depend on the ws' binaryType? https://html.spec.whatwg.org/multipage/web-sockets.html#dom-websocket-binarytype
• The easiest way to determine this seems to be type of the message data. String should be shown normally; while in the Kaazing demo page all other buttons (Blob, ArrayBuffer, Byte Buffer) are received as ArrayBuffer.

Andrea, what is the proper way to check whether WS frame payload is text or binary?

• Do we have an access to WebSocket.binaryType or this is only accessible by JS on the (content) page?
• Should we just check the frame.opCode == nsIWebSocketFrame.OPCODE_BINARY?

Also, how should we properly read the binary data from frame.payload?
We want to see the raw bytes and convert it to Base64 & UTF-8.

Honza

Looking at WS on https://send.firefox.com/ , it uses both text and binary messages, so we need to determine type per message, using opcode.