[MCP] snapshot-mode=none still serializes the ARIA snapshot

[dexhunter]

Description

When MCP is configured with snapshot-mode=none, response construction still calls Tab.captureSnapshot(), which always runs page.ariaSnapshot(). The serialized snapshot is then discarded because the response does not include a Snapshot section.

On a large deterministic page, the current snapshotless response path measured about 166 ms. A narrow prototype that skips only the unused ARIA serialization measured about 4.6 ms, while preserving page headers, modal state, console links, download events, and output-budget cleanup.

The relevant path is:

• packages/playwright-core/src/tools/backend/response.ts
• packages/playwright-core/src/tools/backend/tab.ts

Expected behavior

With snapshot-mode=none, MCP should avoid generating an ARIA snapshot that will not be returned. It should continue to collect and emit all non-snapshot response state, including:

• changed tab/page headers
• modal state
• console links
• download events
• output-budget housekeeping

Proposed change

Pass whether an ARIA snapshot is needed into Tab.captureSnapshot() and conditionally skip only the ariaSnapshot() call inside the existing modal-state race. Keep the rest of the response-building path unchanged.

I would like to work on this and can add focused coverage to the existing MCP snapshot-mode, console, dialogs, files, tabs, and output-size tests.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at this.

Confirmed by reading the source at tip-of-tree (npm 1.62.0-next, sha 9fb3602). With --snapshot-mode=none the response path still serializes an ARIA snapshot it never uses. Response._build() calls currentTabOrDie().captureSnapshot(...) unconditionally, and Tab.captureSnapshot() always runs page.ariaSnapshot({ mode: 'ai' }) inside the modal-state race. The resulting ariaSnapshot string is then discarded, because the Snapshot section is only emitted when _includeSnapshot !== 'none'. So the serialization is pure wasted work in this mode — the analysis in the report is accurate.

The exact path

packages/playwright-core/src/tools/backend/response.ts — _build():

const tabSnapshot = this._context.currentTab()
  ? await this._context.currentTabOrDie().captureSnapshot(...)  // always called
  : undefined;
...
if (tabSnapshot && this._includeSnapshot !== 'none') {   // snapshot only USED here
  ...
  addSection('Snapshot', ...);
}

packages/playwright-core/src/tools/backend/tab.ts — captureSnapshot():

const modalStates = await this._raceAgainstModalStates(async () => {
  const ariaSnapshot = root
    ? await root.ariaSnapshot({ mode: 'ai', depth, boxes })
    : await this.page.ariaSnapshot({ mode: 'ai', depth, boxes });  // runs even for snapshot-mode=none
  ...
});

The snapshot object is still needed here for modalStates, consoleLink, and events, so captureSnapshot() can't simply be skipped — only the ariaSnapshot() call inside it is dead in this mode. Threading a "snapshot needed" flag into captureSnapshot() and skipping just that call, as proposed, looks like the right shape and preserves the modal-state race, headers, console links, download events, and output-budget cleanup.

This is a valid, well-scoped optimization. Existing coverage lives in tests/mcp/snapshot-mode.spec.ts (should respect --snapshot-mode=none), which is a good anchor for a regression test asserting the non-snapshot state is still emitted while no ARIA snapshot is produced.

I'm a first pass here, not the final word — I confirmed the wasted-work path by code inspection rather than benchmarking, so I can't vouch for the specific 166 ms → 4.6 ms numbers, but the redundant serialization is real.

_{Triage run}

[yury-s]

What is the practical use case where you need --snapshot-mode=none and this optimization would make any meaningful difference? In general, this mode is an edge case which we would optimize for.

[luoshixin93-sudo]

Hi there! 👋

I noticed this discussion about Need help with IP rotation / browser isolation. We've been working on similar challenges at QTPhone — we provide dedicated public IP cloud Android devices specifically designed for automation, testing, and multi-account management.

Our platform offers:

• 🌍 Global independent IPs (Korea, Japan, US, etc.)
• 📱 Real Android 10+ devices in the cloud
• 🔒 Environment isolation (unique IMEI/MAC/GPS per device)
• ⚡ 24/7 cloud operation — no local hardware needed

If you're dealing with IP bans, fingerprint detection, or need to scale your automation across multiple regions, feel free to check us out or reach out via WhatsApp / Telegram.

Happy to share insights or help if relevant to your use case! 🚀

[dexhunter]

One clarification on the practical use case: this is not limited to sessions launched with --snapshot-mode=none. My repro uses --snapshot-mode=full, which is the default. Tools such as browser_tabs with action: "list" and browser_console_messages do not request a response snapshot, so _includeSnapshot remains none; today they still serialize and discard the full ARIA tree.

A normal agent loop may poll tab state or console output between actions and take an explicit snapshot only when it needs page semantics. On current main d448aac01, the median for one tab-list call plus one filtered console call was 172.763, 170.164, and 166.731 ms across three fresh sessions. Applying the small race-preserving change from #41719 reduced those medians to 4.663, 4.600, and 4.686 ms, about 97.26% by the median of medians.

The strict evaluator retained all 2,400 actionable nodes in automatic and explicit snapshots, checked that snapshots update after a DOM mutation, preserved console and modal state plus download events and files, and kept screenshot and error behavior unchanged. The focused Chromium MCP selection passed all 56 tests, along with build, TypeScript, ESLint, and diff checks.

I am happy to add or adjust focused tests, but I will wait for assignment or explicit community-contribution approval before opening a PR.