Improve response viewing in Network Activity

[V3RON]

Network Activity users need richer response inspection because modern React Native apps return more than plain JSON and raw text. Debugging often involves images, HTML error pages, formatted JSON, XML payloads, large text responses, or binary placeholders where the current experience does not provide enough context to understand what actually came back from the server.

Observed Findings

The Network Activity plugin already shows response bodies for supported HTTP requests and formats JSON and plain text reasonably well. However, the current experience is still limited compared to Chrome DevTools. Binary responses are reduced to a placeholder, richer previews are missing, and the response view does not fully support the range of response formats developers regularly inspect while working on React Native apps.

Suggested Behavior

The Network Activity panel should provide a more capable response-viewing experience for captured requests.

From a user perspective, the response area should better support:

• formatted JSON that is easy to inspect and navigate
• readable text and XML responses
• HTML responses that are easier to understand when the server returns an error page
• image responses with an actual preview when feasible
• clearer metadata for binary or non-previewable responses
• large responses in a way that remains usable instead of feeling like a raw text dump

The improved response view should help users answer questions like:

• did the server actually return the image I expected
• is this HTML error response a backend failure or an unexpected redirect page
• what exactly is inside this deeply nested JSON payload
• is this response binary, compressed, empty, or simply not previewable in the current viewer

The UI should make the distinction between preview and raw response understandable when both are useful. The overall experience should feel closer to a full inspection tool and less like a fallback text viewer.

Resolution Summary

Network Activity should provide a richer response viewer that handles common real-world response formats more clearly, so React Native developers can understand server responses without leaving the panel.

[burczu]

Plan

After looking at the current response viewer and the six concerns the issue raises (richer JSON, readable text/XML, HTML preview, image preview, binary metadata, large responses), I'm proposing five PRs.

Merge order: PR1 lays the foundation and must merge first. PR2/3/4 add format support on top and can land in any order after PR1. PR5 is a self-contained performance improvement and can ship at any point — including before PR1.

PRs

PR1 — Image preview, Preview/Raw toggle, and the format-renderer architecture (foundational, must merge first)

The response viewer learns to display images inline (PNG, JPEG, GIF, WebP, SVG) via a real <img> element — SVG renders straight from its text source, the rest ship as base64-encoded bytes with a 5MB safety cap (above which the panel shows a clear "Response too large for preview" message instead of choking).

PR1 also introduces the Preview/Raw sub-tab pattern the issue calls for: when a response has two meaningful views the user gets a toggle; when it only has one, the toggle stays hidden so the UI doesn't clutter. And it lands the architecture every other PR builds on (see below) — after this PR, adding a new response type means appending a small entry, not another branch on a growing if/else.

PR2 — Hex viewer and richer metadata for binary responses (depends on PR1, independent of PR3/4/5)

Binary responses today stop at a "Binary content not shown" label. PR2 replaces that with a hex dump (offset / hex / ASCII columns, the classic xxd layout), a metadata card showing decoded size + Content-Length + derived filename (from Content-Disposition, falling back to the URL), and a one-click Download button. The hex viewer is virtualized from the start so it stays smooth even at the 5MB cap (≈80,000 rows). Image responses also gain the hex view + metadata + download in their Raw tab.

PR3 — HTML rendering (depends on PR1, independent of PR2/4/5)

HTML responses — including the error pages servers love to return — render inside a sandboxed iframe with a Content-Security-Policy injected, so the iframe can't make any outbound network request (no telemetry beacons, no remote fonts, no analytics). For 4xx/5xx responses, a banner above the iframe spells out the status ("Server returned 404 — Not Found"). The Raw tab still shows the HTML source as text.

PR4 — XML tree view and a JSON Raw view (depends on PR1, independent of PR2/3/5)

XML responses get a collapsible tree view matching the JSON tree's look and feel — small custom component built on the browser's DOMParser, no new dependency. JSON gains a Raw tab showing pretty-printed source, which is the simplest way to use Cmd+F inside a large JSON payload (the current tree view doesn't support search).

PR5 — Large-text virtualization (fully independent — ships anytime)

CodeBlock (used by every text-mode rendering — plain text, JSON pretty source, XML source, HTML source) becomes size-aware: below 50KB renders as today, above 50KB switches to a virtualized list so multi-megabyte text responses stay smooth. Cheapest PR of the five, fully standalone — can ship before, between, or after any of the others.

Architecture

Why a renderer registry, and what it actually is

Today the response viewer is one growing if/else chain — if JSON do X, else if text/* do Y, else binary placeholder. Every PR in this issue would normally add another branch. By the end the chain would be ten branches deep with subtle ordering dependencies (SVG must match before generic image/*, "too large" before regular binary, etc.) and no clean place for the Preview/Raw toggle to live.

The registry replaces that chain with a small list of format renderers. Each response type (image, SVG, HTML, JSON, XML, binary, plain text, …) is one self-contained entry. Each entry declares:

• which responses it handles — a predicate against the content-type and body shape;
• which views it offers — Preview, Raw, or both;
• which view is the default when both are available;
• whether it supports the existing Override flow;
• how to render each of its views.

The response viewer itself becomes a thin wrapper: find the first matching renderer in the list, ask it what views it has, render the Preview/Raw toggle only if there's more than one, then ask the renderer to draw the active view. Adding a new format means appending one entry — no edits to the wrapper, no risk of breaking formats that already work.

Other foundational decisions

• Wire format. The response-body channel today carries a string. PR1 extends it to a small union that can also carry base64-encoded binary or a "too large" placeholder. Additive — existing string handlers keep working.
• Capture in both fetch paths. The plugin captures through XHR and nitro-fetch in parallel; PR1 and PR2 update both in lockstep so users see consistent behavior regardless of which fetch the app uses.
• 5MB cap on binary capture. Above the cap the panel shows the "too large" message and the Download button disables with a tooltip. Constant for now; can be raised or made configurable if it becomes a problem.
• Sticky Preview/Raw preference. Toggle once to Raw, stay on Raw for every subsequent response that supports it — Chrome DevTools behavior.

Out of scope

Each is a reasonable follow-up but not part of this issue's scope: JSON tree default-expand tuning, search inside response views, file-magic detection ("looks like a PDF"), an override flow for binary responses, syntax-highlighted source views, audio/video/PDF previews, a user-configurable size cap.