fix: WebSocket binaryType handling — stop unconditional Blob interception of binary messages#16173
Conversation
* blob support * pr comments * pr comments * Update DefaultBlobResource.cpp
|
@microsoft/jshost allow me to review before approving. |
|
@JunielKatarn have you had a chance to review? |
|
Beginning review. |
|
I have submitted a PR to your branch adding a test for this use case which will eventually be part of our automation. The change looks correct. |
| /// check MUST also override both TryProcessMessage() overloads to perform the | ||
| /// check-and-process atomically. The default TryProcessMessage() calls Supports() | ||
| /// and ProcessMessage() as two separate operations with no lock held between them. | ||
| virtual bool Supports(int64_t /*socketId*/) noexcept { |
There was a problem hiding this comment.
Rename as CanHandleSocket.
| /// check-and-process atomically. The default TryProcessMessage() calls Supports() | ||
| /// and ProcessMessage() as two separate operations with no lock held between them. | ||
| virtual bool Supports(int64_t /*socketId*/) noexcept { | ||
| return true; |
There was a problem hiding this comment.
No implementation here.
Keep this as a pure-virtual interface.
Same for TryProcessMessage.
| } else { | ||
| } | ||
| if (!handled) { | ||
| args["data"] = message; |
There was a problem hiding this comment.
Please add a comment explaining that the content handler takes over the message payload and thus does not use args["data"].
microsoft-github-policy-service
Bot
added
the
Needs: Author Feedback
2 participants
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