[MCP] context.tracing produces broken archive (metadata-only) after a page crash, permanently, even in a new tab in the same context #42423

Description

context.tracing.stop() produces a broken/empty trace archive (only trace.stacks, missing trace.trace, trace.network, and resources/*) after the page has experienced a renderer disruption (observed via a real crash on chrome://crash, and also via natural heavy/long-running interaction in a real app) — even though the page continues to respond to subsequent tool calls normally, and the same trace worked fine earlier in the same session before the disruption.

The corruption appears to be scoped to the BrowserContext, not the page, and is permanent for that context's remaining lifetime: once it happens, every subsequent tracing.start()/tracing.stop() pair on that context produces the same broken archive, even much later, even against a brand-new tab.

Root cause (as far as I could trace it)

ensureTab() (called by every tool via defineTabTool, e.g. in packages/playwright-core/src/tools/backend/runCode.ts) has a crash-recovery path: it listens for the page's crash event, and if tab.crashed is true, it silently discards _currentTab and calls newTab() to create a replacement — logging "Page crashed and was reset to about:blank." with no signal surfaced to the calling tool or its result. This makes the tool interaction look completely successful even though the tab underneath was just swapped.

That swap happens within the same BrowserContext. I initially assumed re-starting tracing on the new tab (or even a brand-new tab in the same context) would recover clean tracing, since the page object itself is new. It does not — I confirmed via live testing that:

1. Restarting tracing.start()/.stop() on the same context, even scoped tightly around a single subsequent action, still produces a broken archive.
2. Opening a brand-new tab in the same context and tracing that also still produces a broken archive.
3. Only creating a genuinely new BrowserContext (via browser.newContext({ storageState }), copying storage state to preserve the authenticated session) and tracing that produces a valid, complete archive.

This points to some persistent per-BrowserContext state (likely the tracing/CDP session tied to that context) getting wedged after the underlying disruption, independent of which page/tab is asked to trace.

Reproduction

1. Start the MCP server, navigate to any page, log in / set up state as needed.
2. Start a trace: context.tracing.start({screenshots: true, snapshots: true}) (or drive it through whatever the eventual browser_start_tracing-style tool ends up being — I was doing this via browser_run_code_unsafe since there's no dedicated tracing tool today).
3. Trigger a renderer disruption. Easiest deterministic repro: navigate to chrome://crash (fires the same page.on('crash') path ensureTab() listens for). A natural, non-deterministic version of the same failure also showed up organically across ~6 separate real sessions driving a real web app with heavy AI-generated content and long-running network requests — so this isn't purely a crash-URL artifact.
4. Continue driving the page normally with standard tools (they all succeed, no visible error).
5. context.tracing.stop({ path: "trace.zip" }).
6. unzip -l trace.zip — archive contains only trace.stacks (small, metadata-only). No trace.trace, no trace.network, no resources/*. npx playwright show-trace trace.zip on this archive fails to show any recorded actions/network/DOM snapshots.
7. Retrying steps 2–6 later in the same session, same context (even a fresh tab within it) reproduces the same broken archive every time.
8. Repeating steps 2–6 against a brand-new BrowserContext created via browser.newContext({ storageState: await page.context().storageState() }) produces a complete, valid archive.

Environment

• @playwright/mcp 0.0.79
• playwright-core 1.63.0-alpha-2026-08-05
• Browser: Chrome, via --browser=chrome
• Repro'd on Linux (WSL2/Ubuntu)

Impact

Any MCP-driven workflow that (a) runs for more than a couple of minutes, (b) drives a page with heavy/long-running content, or (c) hits any renderer-level hiccup, silently loses tracing for the rest of the session with no error surfaced anywhere — the tool calls all report success, and the only way to notice is to inspect the resulting archive's file listing after the fact.

Suggested fixes (any of these would help)

• Surface the crash-recovery event to the caller somehow (a warning field on the next tool result, a resource, anything) instead of only a server-side log line — right now it's undetectable without independently checking the trace archive contents.
• Expose a way to explicitly reset/replace the MCP-managed BrowserContext (not just the tab) from a tool call, so a caller who detects trace corruption can recover without dropping to raw script + manual storageState copying to work around it.
• If feasible, investigate why context-level tracing doesn't recover after a page crash within that context, even on a fresh page — that seems like the actual underlying issue independent of MCP's own tab management.

Happy to provide the full session transcript / more detail if useful — this took several rounds of live testing to isolate since the failure mode looks like a normal successful session at every step except the final archive contents.