fix: WebSocket binaryType handling — stop unconditional Blob interception of binary messages#16173
Open
gmacmaster wants to merge 8 commits into
Open
Conversation
* blob support * pr comments * pr comments * Update DefaultBlobResource.cpp
Contributor
|
@microsoft/jshost allow me to review before approving. |
Contributor
Author
|
@JunielKatarn have you had a chance to review? |
Contributor
|
Beginning review. |
Contributor
|
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. |
JunielKatarn
requested changes
May 31, 2026
microsoft-github-policy-service
Bot
added
the
Needs: Author Feedback
microsoft-github-policy-service
Bot
removed
the
Needs: Author Feedback
* Add WebSocketArrayBuffer headless test * Skip test by default
Contributor
Author
|
@JunielKatarn Comments addressed |
JunielKatarn
approved these changes
Jun 2, 2026
Performance Test ResultsBranch: ✅ Passed161 scenario(s) across 28 suite(s) — no regressionsSectionList
FlatList
TouchableOpacity
ScrollView
TouchableHighlight
Pressable
Modal
Image
ActivityIndicator
Switch
Button
TextInput
View
Text
SectionList.native-perf-test.ts
FlatList.native-perf-test.ts
TouchableHighlight.native-perf-test.ts
TouchableOpacity.native-perf-test.ts
Pressable.native-perf-test.ts
ScrollView.native-perf-test.ts
ActivityIndicator.native-perf-test.ts
TextInput.native-perf-test.ts
Switch.native-perf-test.ts
Button.native-perf-test.ts
Modal.native-perf-test.ts
Image.native-perf-test.ts
View.native-perf-test.ts
Text.native-perf-test.ts
|
Contributor
|
/azp run |
Contributor
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@acoates-ms these are just the random failures right? Just needs a rerun? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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