Browser Use: add lightweight page text extraction for heavy SPAs

Open 💬 0 comments Opened Jun 1, 2026 by liweichao-coder

Proposal

Add a Browser Use page-text extraction command/capability that is implemented on the browser/extension side, similar in spirit to a get_page_text API.

The goal is to provide a safe, bounded, low-latency way to read rendered page text from heavy SPAs without requiring agents to call broad DOM operations such as:

await tab.playwright.locator(body).innerText(...)
await tab.playwright.domSnapshot()

Those full-page DOM/text paths can hang or time out on real-world authenticated dashboards, virtualized lists, and large front-end apps, even when navigation, title/url reads, and screenshots work.

Why this matters

I hit this on a logged-in task dashboard SPA:

  • Chrome Browser Use could open the page and read the tab title/URL.
  • Screenshots worked.
  • Full-page text/DOM extraction timed out repeatedly.
  • A screenshot-driven workaround could read the task list, but it is brittle and not suitable for recurring automations.

The same pattern is related to, but broader than, #22797. That issue reports real-page DOM inspection timeouts. This proposal asks for a narrower fallback capability: extract useful rendered text under explicit budgets, without exposing the entire DOM tree.

Suggested API shape

One possible shape:

type PageTextOptions = {
  selector?: string;
  visibleOnly?: boolean;
  maxChars?: number;
  maxNodes?: number;
  timeoutMs?: number;
};

type PageTextResult = {
  text: string;
  truncated: boolean;
  elapsedMs: number;
  source: accessibility | visible-dom | dom-snapshot | tree-walker;
};

await tab.pageText.get(options);

A command-style tool name would also be fine, for example tab_get_page_text or browser_get_page_text.

Behavioral requirements

  • Default to bounded output, for example maxChars and maxNodes.
  • Enforce timeoutMs inside the browser/extension side rather than letting a model-side tool call hang.
  • Prefer visible/rendered text over raw DOM text.
  • Support selector so an agent can read a specific panel, modal, article, table, or task list instead of the entire page.
  • Return whether output was truncated.
  • Avoid reading hidden text by default.
  • Exclude password fields and avoid dumping form values unless explicitly designed and reviewed.
  • Do not inspect cookies, local storage, session storage, extension storage, or browser profile data.
  • Work for both Chrome extension and in-app browser backends if they share Browser Use command plumbing.

Possible implementation approaches

I do not have access to the proprietary Browser/Chrome plugin source, so this is a design-level proposal rather than a code PR.

Implementation options that should avoid the worst innerText behavior:

  1. Use an accessibility-tree or rendered-text snapshot where available.
  2. Use a TreeWalker over text nodes with node/time/character budgets.
  3. Only include nodes with visible layout boxes when visibleOnly is true.
  4. Support a scoped selector first, then walk only that subtree.
  5. Abort and return partial text when budgets are reached instead of timing out the whole tool call.

Test plan

Useful tests would include:

  • A large synthetic SPA page where document.body.innerText is slow or impractical, but the new command returns within its timeout budget.
  • A virtualized task list or dashboard panel, using selector to extract only the visible list.
  • Hidden nodes and display: none text are omitted when visibleOnly is true.
  • Password fields are always excluded.
  • maxChars truncates deterministically and sets truncated: true.
  • Timeout budget returns partial text plus metadata rather than hanging.
  • Browser Use security checks still gate the target origin before extraction.

Contribution note

I checked the public openai/codex repository first, but the Browser/Chrome plugin manifests point to an OpenAI-internal/proprietary Browser Use plugin source location, and the public contributing guide says unsolicited code PRs are not accepted. I am opening this issue with reproduction details, proposed API shape, and test coverage suggestions per that guidance.

View original on GitHub ↗