feat(mcp): add `compress` option to `browser_snapshot` to collapse repeated ARIA nodes

[Josef-Le]

Problem

On pages with large lists, data grids, or autocomplete menus, the ARIA snapshot returned by browser_snapshot can grow to thousands of lines. A GitHub issues page with 100 open issues produces ~1 800 lines; a spreadsheet with 500 rows produces ~6 000 lines. The vast majority of that content is structurally identical — only the text and element ref differ — so the model learns nothing from seeing item #51 through #500.

This wastes tokens, slows inference, and can cause the model to miss important interactive elements buried in the noise.

Proposed solution

Add a compress?: boolean parameter to browser_snapshot.

When true, a two-pass algorithm collapses repeated sibling nodes:

1. Pre-scan (safety gate): Normalise every line to a structural signature (strip [ref=eN], accessible names, and numbers) and count how often each (indent, signature) pair appears. Only proceed if the maximum count exceeds 100 — this prevents false positives on diverse pages like dashboards.
2. Compression pass: Walk the YAML line by line. Keep the first 10 occurrences of any repeated structural pattern; collapse the rest (along with their descendant subtrees). Elements with interactive roles (button, input, link, checkbox, …) are always kept.
3. Trailing note: Append a line explaining what was removed and directing the model to use browser_evaluate() for full enumeration.

Example

A page with 150 <li>Item N</li> elements:

Before (152 lines):

- list [ref=e2]:
  - listitem [ref=e3]: Item 1
  - listitem [ref=e4]: Item 2
  ...
  - listitem [ref=e152]: Item 150

After (compress: true, 13 lines):

- list [ref=e2]:
  - listitem [ref=e3]: Item 1
  - listitem [ref=e4]: Item 2
  ...
  - listitem [ref=e12]: Item 10

[playwright-compress: 140 repeated ARIA nodes collapsed — use browser_evaluate() to enumerate the full list]

Implementation plan

• packages/playwright-core/src/tools/backend/ariaCompression.ts — pure compression function
• packages/playwright-core/src/tools/backend/snapshot.ts — add compress to browser_snapshot input schema (zod)
• packages/playwright-core/src/tools/backend/response.ts — wire compress through setIncludeFullSnapshot() to the injection point
• tests/mcp/snapshot-compression.spec.ts — 4 tests covering: happy path, passthrough on small lists, interactive-element preservation, compress: false escape hatch

Design decisions

Decision	Rationale
FIRE_THRESHOLD = 100	A typical nav/sidebar has <20 items; a real pagination list has >100. This prevents false positives on diverse pages.
KEEP_N = 10	Enough examples for the model to understand the list structure without excessive verbosity.
Always keep interactive roles	Buttons, inputs, links, checkboxes, etc. carry distinct meaning even when visually identical.
Explicit opt-in (compress: true)	The model chooses when compression is appropriate; it is never forced on.
Trailing note	Tells the model that data was removed and provides a concrete action (browser_evaluate()) to retrieve it.

I intend to work on this and have a draft implementation ready.

[dgozman]

@Josef-Le There is a depth option that allows agent to iteratively explore the page without taking a full snapshot. Have you tried using that?

[pavelfeldman]

Where can I find an issues page with 500 issues in a list, isn't it paginated?

[Josef-Le]

Thanks for the questions — let me address both.

@dgozman — depth vs compress are orthogonal axes

depth limits vertical tree traversal (nested DOM structure). compress collapses horizontal repetition (many siblings at the same depth). A <ul> with 500 <li> items is only 2 levels deep — depth=2 returns all 500 items unchanged. The two options don't overlap.

@pavelfeldman — the GitHub issues example was a bad pick

You're right that GitHub issues are paginated; the line-count claim was off. Better examples where the problem is real:

• <select> with 200+ <option> elements (common in country/state pickers)
• Autocomplete dropdowns that render all matches in the DOM at once
• HTML <table> with 200 rows (no virtual scroll, fully in the ARIA tree)
• A long <nav> or sidebar with 150+ links (e.g. a docs TOC)
• Infinite-scroll feeds where past items stay in the DOM

These are all flat or near-flat structures where depth does nothing and the ARIA snapshot genuinely bloats to thousands of lines of structurally identical content.

The underlying problem is real. Happy to update the issue description with these examples if that helps the triage.

[pavelfeldman]

The underlying problem is real. Happy to update the issue description with these examples if that helps the triage.

I'd appreciate a concrete example on the publicly accessible page (not artificial test, a real web page and a real agentic scenario with a task on that page.