fix: capture network on Safari and Appium sessions without BiDi

[vishnuv688]

Summary

Reported on the launch post: network calls are not available for Safari and Appium. Network capture rode on WebDriver BiDi, or on Chrome's performance log in Nightwatch, and neither exists on Safari or on a session Appium serves, so those sessions showed an empty Network tab.

• The page collector reads the document's Resource Timing buffer (packages/script/src/collectors/resourceTiming.ts). Every browser keeps it: each load with its timing phases and size, on Chromium its status, never headers or bodies. The buffer is read at install, so loads made before the collector existed are included, then observed. The collector's existing fetch/XMLHttpRequest patch claims each call it sees, so a request both saw is listed once with the patch's headers and body.
• A driver-side source wins once it has delivered, not once it is subscribed. On Appium 3.7's XCUITest driver the BiDi inspectors attach cleanly and then send nothing, so gating on the subscription withheld the page's rows and left zero network rows. Each adapter now latches on the first BiDi network event it receives and gates on that; the Selenium adapter applies the same rule to its console gate.
• Nightwatch's performance log upgrades the page's row in place. The log is read after the page is drained, so each entry is paired with the page's row for the same load and lays its headers and status over it under the row's id. A load the log listed first is dropped from the next drain. A session whose capabilities name a performance log the driver never serves is no longer left empty.
• The Python adapter no longer treats safaridriver's echoed webSocketUrl: true as a BiDi endpoint. It is a boolean, not a socket address, and selenium's connection thread crashed on it.
• What Resource Timing cannot see is stated. The row carries source: 'resource-timing', the Network tab colours a status-less row as unknown rather than pending, the detail card names what the browser does not expose, and the HAR entry carries _source and _resourceType so a reopened trace renders the same row rather than a failed request.

Found on the way and fixed in its own commit: Selenium and Nightwatch traces on Chrome listed every BiDi request twice, a pending row beside the completed one. selenium-webdriver's NetworkInspector hands every network event to every subscriber's callback, so the request handler also received responses and the response handler received requests. packages/core/src/bidi.ts now ignores the other handler's events by shape, keeps rows by request id so a redirect hop continues its row, and reads network.fetchError off the inspector's own connection so a request the browser gives up on closes as a failure instead of staying pending.

Native app sessions have no document and still have no network capture; only a device- or proxy-level capture sees that traffic.

Verification

Platform	WDIO	Selenium	Nightwatch	Python
Chrome (BiDi)	unchanged	one row per request, no duplicates	one row per request, no duplicates	unchanged
Desktop Safari 26.5	Resource Timing rows	Resource Timing rows	Resource Timing rows	Resource Timing rows
iOS 26.5 Safari, Appium 3.7	Resource Timing rows	Resource Timing rows	Resource Timing rows	Resource Timing rows
Android	not verified, no SDK on this machine

• pnpm test: 2599 tests across 196 files, green.
• pnpm lint: 0 errors. tsc --noEmit: clean. pnpm build: clean, and the workspace-package leak grep over every dist is empty.
• pnpm test:ui: 31 specs green.
• Python suite: 723 passed; the 2 failures also fail on main.

Follow-ups, not in this PR

• The WebdriverIO website docs need the same "without BiDi" paragraph mirrored; this PR updates the READMEs and examples/MOBILE.md here.
• The Python adapter's login example on desktop Safari is flaky before and after this change, documented in CLAUDE.md. Network capture worked in every run.
• Android device verification.
• Conformance coverage for the Network tab in the three BiDi modes is on a separate branch.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge, with a non-blocking slowdown in network capture on long runs.

Findings

1.  Network capture slows over time ▶

Summary

Adds page-based network capture for Safari and Appium sessions without working BiDi events.

• Safari and Appium sessions now show network rows from the page.
• Nightwatch performance logs fill in matching page rows.
• BiDi request events now update one network row per request.
• Selenium keeps Safari in front and instruments new pages before commands continue.
• Wait polls now fold into the command that started them.
• Shared request helpers give captured loads consistent types and URL filtering.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Page requests] --> B[Fetch and XHR patch]
  A --> C[Resource Timing]
  B --> D[Match claims and keep one row]
  C --> D
  D --> E[Adapter drain]
  F[Delivered BiDi events] --> E
  E --> G[Dashboard and saved trace]

Loading

_{Reviews (4) · Last reviewed commit: "fix(selenium): fold only a wait()'s own ..." · Reviewed by Greptile}

[greptile-apps]

Network capture slows over time

Every incoming request now runs findIndex over all requests saved so far, including new ids. Capturing N requests therefore takes roughly N²/2 comparisons instead of appending them directly. Busy pages and long runs spend increasing time draining network data. Use an id lookup so replacing a released row does not require scanning the whole recording.