fix: WebSocket binaryType handling — stop unconditional Blob interception of binary messages

[gmacmaster]

Description

WebSocket binaryType = 'arraybuffer' is silently broken on React Native Windows.

Type of Change

Bug fix (non-breaking change which fixes an issue)

Why

WebSocket binaryType = 'arraybuffer' is silently broken on React Native Windows. All binary WebSocket messages are unconditionally intercepted by BlobWebSocketModuleContentHandler and converted to Blobs, regardless of whether the socket has been registered for blob handling via addWebSocketHandler. This means:

Setting binaryType = 'arraybuffer' has no effect — binary messages still arrive as Blobs
The JavaScript-side WebSocket.js never executes its base64-to-ArrayBuffer conversion path for binary messages
Applications relying on ArrayBuffer delivery (e.g., PowerSync, binary protocol clients) are forced to implement custom Blob-to-ArrayBuffer conversion patches
This diverges from the behavior on iOS and Android, where binaryType correctly controls binary message delivery format.

What

The root cause is in DefaultBlobResource.cpp: IBlobResource::Make() unconditionally registers a BlobWebSocketModuleContentHandler on the ReactContext property bag, and WebSocketModule.cpp routes all binary messages through it without checking whether the specific socket was registered via addWebSocketHandler.

The BlobWebSocketModuleContentHandler already tracks registered socket IDs in m_socketIds (populated by Register/Unregister), but this set was never consulted during message processing.

Changes across 4 files:

IWebSocketModuleContentHandler.h — Changed both ProcessMessage overloads from void to bool return type. true = message was handled by the content handler; false = caller should fall back to default delivery.

DefaultBlobResource.h — Updated BlobWebSocketModuleContentHandler::ProcessMessage signatures to return bool.

DefaultBlobResource.cpp — Both ProcessMessage overloads now read the socket ID from params["id"], acquire m_mutex, and check m_socketIds. If the socket is not registered, they return false without processing. This check is atomic with the message processing, avoiding any TOCTOU gap between a separate Supports() check and ProcessMessage.

WebSocketModule.cpp — The SetOnMessage callback now checks the bool return value from ProcessMessage. If false, it falls through to the default path (args["data"] = message), which delivers the base64-encoded binary data to JavaScript where WebSocket.js decodes it to an ArrayBuffer.

Behavior after the fix:

binaryType = 'blob' (socket registered via addWebSocketHandler) — binary messages delivered as Blobs, same as before.
binaryType = 'arraybuffer' or default (socket not registered) — binary messages delivered as ArrayBuffer via the standard JS-side base64 decode path.
Screenshots
N/A — this is a data-path fix with no UI changes. Verified by observing WebSocket message delivery type in application-level diagnostics.

Testing

Verified end-to-end on a Windows device running a React Native application with PowerSync (real-time sync over binary WebSocket):

Before fix: All binary messages hit Blob conversion path (fileReader branch in application diagnostic stats), binaryType = 'arraybuffer' caused silent message drops.
After fix: All binary messages hit the passthrough/ArrayBuffer path (passthrough branch active, fileReader: 0), no message drops.
Tested both binaryType modes:

'arraybuffer' — messages arrive as ArrayBuffer in MessageEvent.data (was broken, now works)
'blob' — messages arrive as Blob in MessageEvent.data (still works, no regression)

Changelog

Should this change be included in the release notes: yes

Fix WebSocket binaryType handling on Windows — binary messages are no longer unconditionally converted to Blobs. Sockets using binaryType = 'arraybuffer' (the standard default) now correctly receive ArrayBuffer data.

Microsoft Reviewers: Open in CodeFlow

[JunielKatarn]

@microsoft/jshost allow me to review before approving.