Add CDP support for WebSocket events (iOS)#57543
Closed
huntie wants to merge 1 commit into
Closed
Conversation
Summary: **Context** This stack implements WebSocket event debugging for the Network panel in React Native DevTools. React Native DevTools' Network support launched with fetch, XHR, and Image traffic, but WebSocket connections are invisible today. Discussed with Expo earlier this year, we want upstream parity before Expo adopts the 1P Network panel. This is a comparatively small surface: 6 CDP events, no CDP methods. **Minimum goal**: Parity with Expo's current WS event coverage. We improve on this with Request Initiator support in D111561995. **This diff** Adds first-party reporting for six of the seven WebSocket CDP events (`webSocketCreated`, `webSocketWillSendHandshakeRequest`, `webSocketHandshakeResponseReceived`, `webSocketFrameSent`, `webSocketFrameReceived`, `webSocketClosed`), mirroring the layering of the existing HTTP pipeline: - **C++ core**: WebSocket CDP types and reporting APIs through `CdpNetwork` → `NetworkHandler` → `NetworkReporter`. Compiled to no-ops in production builds; inert unless the Network domain is enabled. - **iOS**: a new `RCTInspectorWebSocketReporter` bridges `RCTWebSocketModule` to `NetworkReporter`, reporting connection lifecycle, real handshake headers, and sent/received messages. Android follows separately. - **Gating**: a new `fuseboxWebSocketEventsEnabled` feature flag (experimentation, default off), checked alongside `enableNetworkEventReporting`. **Omitted from the spec, and why** - [`Network.webSocketFrameError`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#event-webSocketFrameError) — the one unimplemented event. Neither SocketRocket nor OkHttp exposes a frame-scoped error; connection failures are terminal and already reported via `webSocketClosed`. Cheap to bolt on once a genuine per-message error source exists (e.g. OkHttp `send()` returning false). - Ping/pong and close frames (opcodes 8–10) — not surfaced by the native socket APIs (OkHttp has no ping/pong callbacks). Chrome renders these as extra Messages rows; the practical loss is that close code/reason isn't visible, since `webSocketClosed` itself has no fields for them. - Optional [`WebSocketResponse`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#type-WebSocketResponse) fields (`headersText`, `requestHeaders`, `requestHeadersText`) — we report structured headers only; raw handshake text isn't available from OkHttp on Android. - No `performance-timeline` or tracing integration — WebSocket events report to CDP only; unlike HTTP, there is no `PerformanceResourceTiming` counterpart to populate. **Rollout plan** (New `enableNetworkEventReporting` flag) - 0.88 - Canary channel - 0.89 - Stable channel Changelog: [Internal] Differential Revision: D111561998
meta-cla
Bot
added
the
CLA Signed
|
@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111561998. |
huntie
changed the title
|
This pull request has been merged in 020512b. |
meta-codesync Bot
pushed a commit
that referenced
this pull request
Jul 15, 2026
…ude-health ratchet (#57565) Summary: After the SwiftPM stack landed (#57332), the `prebuild_react_native_core / compose-xcframework` jobs (Debug and Release) went red on the **"Verify composed headers"** step (`headers-verify.js`), not on the XCFramework compile: ``` include-health ratchet: 2 NEW unresolvable include(s) in shipped headers (work in source builds via pod header maps, break the packaged layout): unresolved CoreModules/RCTInspectorWebSocketReporter.h -> CFNetwork/CFNetwork.h unresolved React/RCTInspectorWebSocketReporter.h -> CFNetwork/CFNetwork.h ``` `React/CoreModules/RCTInspectorWebSocketReporter.h` (added in #57543, "Add CDP support for WebSocket events (iOS)") does `#import <CFNetwork/CFNetwork.h>` because it uses `CFHTTPMessageRef`. The include-health ratchet classifies any include whose first path segment isn't in the `SDK_PREFIXES` allowlist in `headers-inventory.js` as `unresolved`. **`CFNetwork` was missing from that allowlist** — even though it's a genuine Apple system framework that's always available in the SDK, exactly like `CoreFoundation`, `Security`, and `Network`, which are already listed. (Two offenders because the same header ships under two natural paths, `CoreModules/` and `React/`.) ## Fix Add `CFNetwork` to `SDK_PREFIXES`. This is the accurate classification (it's a system framework), so **no baseline change is required**. ## Changelog: [INTERNAL] [FIXED] - Classify `CFNetwork` as a system framework in the prebuilt-header include-health ratchet Pull Request resolved: #57565 Test Plan: - Ran the include-health stage locally against the source tree + committed `headers-include-baseline.json`: `CFNetwork` is no longer flagged, **0 new offenders, 0 baseline entries to shrink**. - `ios-prebuild` unit suite: **56/56 pass**. Reviewed By: cortinico Differential Revision: D112115176 Pulled By: cipolleschi fbshipit-source-id: 1bf28d5dae361e88c85c4f4678aeb9b4b9c6c7ca
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
1 participant
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.
Summary:
Context
This stack implements WebSocket event debugging for the Network panel in React Native DevTools.
Discussed with Expo earlier this year, we want upstream parity before Expo adopts the 1P Network panel. This is a comparatively small surface: 6 CDP events, no CDP methods.
Minimum goal: Parity with Expo's current WS event coverage. We improve on this with Request Initiator support in D111561995.
This diff
Adds first-party reporting for six of the seven WebSocket CDP events (
webSocketCreated,webSocketWillSendHandshakeRequest,webSocketHandshakeResponseReceived,webSocketFrameSent,webSocketFrameReceived,webSocketClosed), mirroring the layering of the existing HTTP pipeline:CdpNetwork→NetworkHandler→NetworkReporter. Compiled to no-ops in production builds; inert unless the Network domain is enabled.RCTInspectorWebSocketReporterbridgesRCTWebSocketModuletoNetworkReporter, reporting connection lifecycle, real handshake headers, and sent/received messages. Android follows separately.fuseboxWebSocketEventsEnabledfeature flag (experimentation, default off), checked alongsideenableNetworkEventReporting.Notes
Network.webSocketFrameError. Neither SocketRocket nor OkHttp exposes a frame-scoped error; connection failures are terminal and already reported viawebSocketClosed. Cheap to bolt on once a genuine per-message error source exists (e.g. OkHttpsend()returning false).WebSocketResponsefields (headersText,requestHeaders,requestHeadersText) — we report structured headers only; raw handshake text isn't available from OkHttp on Android.performance-timelineintegration — WebSocket events report to CDP only; unlike HTTP, there is noPerformanceResourceTimingcounterpart.Rollout plan (New
enableNetworkEventReportingflag)Changelog: [Internal]
Differential Revision: D111561998