fix(mcp): report capped time in browser_wait_for

[Yury Semikhatsky (yury-s)]

Summary

• browser_wait_for caps time at 30s, but both the generated code and the result reported the requested value. Now both report the time actually waited, and the result mentions the cap when it applies.
• The time parameter description now states the 30s maximum.

The cap dates back to the initial playwright-mcp commit (10s, later bumped to 30s) without a stated rationale. Likely reasons:

• Guarding against models confusing units, e.g. time: 5000 meaning 5s would block the session for ~83 minutes.
• Staying under MCP client request timeouts (the MCP TS SDK defaults to 60s), so the client doesn't give up while the wait is still running.

Fixes microsoft/playwright-mcp#1767

[github-actions]

Test results for "MCP"

1 failed
❌ [msedge] › mcp/http.spec.ts:624 › should close session when heartbeat ping is not answered @mcp-windows-latest-msedge

8763 passed, 1480 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

🟢 The one failure is a pre-existing flake

mcp/http.spec.ts:624 (heartbeat ping) failed once on Windows msedge. It has failed the same way on main and on an unrelated PR, and this PR only touches browser_wait_for.

Details

The latest MCP report has a single failure out of 8764 tests. The new and updated tests in mcp/wait.spec.ts passed.

Pre-existing flake / infra

• [msedge] › mcp/http.spec.ts:624 › should close session when heartbeat ping is not answered (mcp-windows-latest-msedge). The test waits for the HTTP transport to drop a session after a missed heartbeat. That code path doesn't go near packages/playwright-core/src/tools/backend/wait.ts, the only product file this PR changes. The test-results DB has this same test failing with the same error (expect.poll timed out, Expected: 1, Received: undefined for delete http session) in two runs this PR can't have caused:

  • firefox, mcp-windows-latest-firefox, push to main
  • webkit, mcp-macos-latest-webkit, #42922, which is an unrelated download-crash fix

  It's rare: about 1 failure in roughly 700 runs per browser. Still, it's the same test with the same signature on unrelated SHAs, across different browsers and OSes, so this looks timing-sensitive rather than a regression. I couldn't add this PR's own run to the DB (the local update step got an API 500), so the history above comes from the shared snapshot.

_{Triaged by the Playwright bot - agent run}