fix(extension): capture initial-page-load XHR/fetch bodies (injection-timing race)

[nafees87n]

What

Fixes a v2 body-capture bug: an SPA's initial page-load XHR/fetch responses were missed, so LTS auto-correlation chained 0 rows (those bootstrap responses carry the IDs/slugs correlation needs).

Stacked on #66 (advanced settings) — base branch is feat/network-recording-advanced-settings. Re-target to master once #66 merges.

Refs RQ-2894.

Root cause

The web-sdk fetch/XHR interceptor was injected via executeScript from webNavigation.onCommitted and only armed on the START round-trip — so it landed after the page's first requests fired. Those request bodies were never captured (no webRequest fallback for xhr/fetch — it's hard-suppressed). On fast/cached SPAs this silently lost the correlation-critical bootstrap responses.

Fix — register before navigation, buffer from t=0

• about:blank → register → navigate: create the recorded tab at about:blank, open the side panel synchronously (preserves the sidePanel.open() user gesture — about:blank doesn't consume it), then await registering the web-sdk UMD + body recorder as one ordered document_start MAIN-world content script (registerContentScripts), then chrome.tabs.update to the real URL. The interceptor is guaranteed armed before request bug: 307 in mock server leads to failure when used user with net:http module #1, and the URL loads exactly once (no double-send).
• Buffer-until-START: the page script arms the interceptor at injection and buffers captures until START, then flushes — so even an early request is retained.
• Pull-based READY→START handshake with retry: the page re-posts READY until START arrives. (A one-shot READY raced the content-script relay on fast loads and silently dropped, leaving the buffer un-flushed → 0 entries. This was the practicesoftwaretesting.com failure.)
• Non-http(s) guards: clientHandler + tabService onCommitted/onDOMContentLoaded handlers now skip non-http(s) URLs, so the about:blank step doesn't log "Cannot access contents of url about:blank" / "Receiving end does not exist".
• Lifecycle: unregister the body-recorder scripts when the last recording stops; clean up orphaned registrations on SW init.

Also

• Raise DEFAULT_MAX_PAYLOAD_SIZE 200KB → 10MB — a "safe maximum": covers realistic API/JSON bodies, stays well under Chrome's ~32MB chrome.runtime.sendMessage ceiling (bodies stream one-per-message) so an oversized body truncates gracefully (RESPONSE_TOO_LARGE flag) instead of throwing and losing the entry. (An earlier LTS run sent maxPayloadSize: 200 — 200 bytes — and stripped all bodies; unit is bytes, documented.)

Known limitation (documented, not coded around)

START/flush delivery rides the client content-script relay, which attaches only on HTML top documents. A recorded tab whose top document is non-HTML (raw JSON/XML/no-doctype) won't capture xhr/fetch bodies. Acceptable — LTS records web apps, not raw endpoints. A comment documents how to add an SW-side watchdog if that assumption ever changes (deliberately not added — avoids machinery for a case real targets don't hit).

Approach validation

The about:blank approach was chosen after a head-to-head evaluation (vs. CDP/debugger, static-shim, accept-the-race). It's the only one that structurally guarantees request #1 is captured (await-before-navigate → document_start ordering), with zero new permissions. CDP was rejected (persistent debugging banner, mutual-exclusion with the user's DevTools, debugger permission, not race-free for body retrieval).

Testing

Manually validated on realworld.show and practicesoftwaretesting.com (the latter intermittently failed before the READY-retry fix): bootstrap XHRs captured with request+response bodies, panel counts them, no double-send, side panel opens, no console errors.

Build clean (only pre-existing TS7030/circular-dep warnings).

🤖 Generated with Claude Code