`wait_for` never finds visible text whose HTML source contains line breaks or repeated spaces

Open Beginner friendly
  • Is something wrong?
#2,947 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@a5768549 is already working on this.

Since Oct 26, 2026.

  • #3350 by @a5768549 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
testing-qa

Research direction

Start with McpPage.waitForTextOnPage in src/McpPage.ts:1132-1149 and the wait_for description and tests in src/tools/snapshot.ts:49-61. Reproduce using the supplied /spaces.html fixture and compare wait_for with the snapshot text. Done when normalized paragraph text succeeds, the button still succeeds, and absent text still times out.

Written by the indexing model from the issue text.

Description

confirmed p3
Description of the bug

wait_for times out on text that is visible on the page and shown verbatim in take_snapshot when the element's HTML source contains a line break, indentation or repeated spaces inside the text. For <p>Order\n confirmed</p>, the snapshot shows StaticText "Order confirmed", but wait_for with ["Order confirmed"] fails with Timed out after waiting 2000ms. Source formatting like this is common in real pages, and agents naturally copy text from the snapshot, so wait_for reports a timeout for content that is already on screen. Both tested builds behave the same.

Actual behavior

Identical on both builds:

take_snapshot
uid=2_1 StaticText "Multi spaced words"
uid=2_2 StaticText "Order confirmed"
uid=2_3 button "Place order"

wait_for ["Multi spaced words"]  isError=true   ~2003 ms  "Error: Timed out after waiting 2000ms"
wait_for ["Order confirmed"]     isError=true   ~2003 ms  "Error: Timed out after waiting 2000ms"
wait_for ["Place order"]         isError=false   8-10 ms  "Element matching one of [\"Place order\"] found."

(The main build prints snapshot text nodes without the StaticText role label; the strings are the same.) The button matches because its accessible name is whitespace-normalized; the paragraphs have no accessible name and only the raw-text match is tried.

Reproduction
  1. Serve this page as /spaces.html (the second paragraph and the button contain a newline followed by four spaces):
<!doctype html><title>Spaces</title>
<p>Multi   spaced    words</p>
<p>Order
    confirmed</p>
<button>Place
    order</button>
  1. Send these calls in order:
{"name":"navigate_page","arguments":{"pageId":1,"url":"http://127.0.0.1:PORT/spaces.html"}}
{"name":"take_snapshot","arguments":{"pageId":1}}
{"name":"wait_for","arguments":{"pageId":1,"text":["Multi spaced words"],"timeout":2000}}
{"name":"wait_for","arguments":{"pageId":1,"text":["Order confirmed"],"timeout":2000}}
{"name":"wait_for","arguments":{"pageId":1,"text":["Place order"],"timeout":2000}}

The button is a control. Ran once per build for this report; an earlier independent run of the repeated-spaces paragraph timed out the same way on both builds.

Expectation

wait_for is described as "Wait for the specified text to appear on the selected page." with text "Resolves when any value appears on the page." (src/tools/snapshot.ts:49-61 at the main commit; docs/tool-reference.md). The page renders these paragraphs as "Multi spaced words" and "Order confirmed", and the server's own snapshot reports exactly those strings. Text that appears on the page as rendered, and as the snapshot shows it, should satisfy wait_for.

MCP configuration

--headless --isolated --no-usage-statistics --no-performance-crux unless the reproduction states otherwise (update checks disabled with CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=1).

Chrome DevTools MCP version

1.10.1 (npm) and main 5ddb0a3110c5059f8e5513e566196cce2a35c6d1 (local build)

Chrome version

154.0.8037.98 (stable)

Node version

v22.23.2

Operating system

macOS 27.0

Environment details
  • chrome-devtools-mcp 1.10.1 from npm (the release build).
  • chrome-devtools-mcp built from main at commit 5ddb0a3110c5059f8e5513e566196cce2a35c6d1 (the main build; its server info still reports version 1.10.1).
  • Google Chrome 154.0.8037.98 stable, headless; Node v22.23.2; macOS 27.
  • Both builds were started with --headless --isolated --no-usage-statistics --no-performance-crux and CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=1, and driven by a scripted stdio MCP client that sends one tools/call at a time and records isError and wall time. Fixtures were served from a loopback HTTP server on an ephemeral port (PORT below); any static server, such as python3 -m http.server --bind 127.0.0.1, serves the static fixtures the same way.
Evidence
  • Expected source: wait_for description and text parameter text (src/tools/snapshot.ts:49-61 at the main commit); the strings in the same server's take_snapshot output.
  • Failure source: scripted MCP run above on both builds. Static breadcrumb (inferred from source and the button control): McpPage.waitForTextOnPage (src/McpPage.ts:1132-1149) races aria/<text> (accessible name, normalized) and text/<text> (DOM text content, not whitespace-collapsed) locators, so text in non-named elements must match the source whitespace exactly.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete
Fix check

With the steps above, wait_for with ["Order confirmed"] and with ["Multi spaced words"] each return success promptly. Controls that pass today on both builds and must keep passing: ["Place order"] still succeeds, and a string that is not on the page (["Order cancelled"]) still times out.

Additional context

The full open and closed issue and PR corpus was screened as of 2026-10-06 (searches included wait_for whitespace, wait_for text); no issue reports this.

Two other wait_for mismatches with the snapshot were observed in the same investigation and are reported separately because each has its own failing input: text hidden with display:none is reported as found, and text inside an iframe attached after the call starts is never found.

Dominant language
TypeScript
Stars
54.6k
Forks
5.2k
Avg merge
1d 15h
Merged PRs (30d)
218

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ChromeDevTools/chrome-devtools-mcp

All issues in ChromeDevTools/chrome-devtools-mcp

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.