Add CDP support for WebSocket events (iOS)#57543
Open
huntie wants to merge 1 commit into
Open
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
|
@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111561998. |
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
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