Understand network capture and its limits

The BugMojo extension records the network requests your page makes while you reproduce a bug: the URL, method, status, timing, and masked headers. Request and response bodies are never captured. This gives whoever picks up the report the API-level story behind a failure. But browsers guard network data for good reasons, so capture has honest limits. Here is how it works and where it stops.

When a capture starts, the extension wraps the page's fetch and XMLHttpRequest APIs so every call flows through BugMojo first. Your app still receives its own untouched request and response. Capture never breaks the page it watches. For each request we store:

• Method and URL, such as POST /api/checkout.
• Status and timing: the response code and round-trip duration.
• Headers, request and response, after redaction.

Request and response bodies are not stored, whatever their size or type. They are dropped in the browser and never sent to BugMojo.

Browsers deliberately hide some network data, so expect these gaps:

• Opaque cross-origin responses: a fetch made in no-cors mode returns an opaque response the page itself cannot read, so neither can we. You will see the request, but the status stays blank.
• CORS-blocked reads: if a cross-origin server does not send permissive CORS headers, the browser hands your app an error instead of a response. BugMojo logs the attempt and the error.
• Timing races: requests still in flight when the capture stops are recorded as pending, without a final status.
• Bodies of any kind: JSON, form data, streams, file downloads, and images are never stored; only the request line, status, timing, and masked headers are.
• Non-page traffic: requests made by other browser extensions, service workers, or other tabs are outside the page we hook and are not captured.