Revert "feat(webmcp): add page.webmcp API"

[Pavel Feldman (pavelfeldman)]

Reverts #42979

[github-actions]

Test results for "MCP"

3 failed
❌ [chrome] › mcp/console.spec.ts:435 › browser_console_messages all option for page errors @mcp-macos-latest-chrome
❌ [firefox] › mcp/idle-timeout.spec.ts:19 › closes the browser after the idle timeout and relaunches it on the next call @mcp-windows-latest-firefox
❌ [webkit] › mcp/annotate.spec.ts:386 › should cancel browser_annotate when the MCP request is aborted @mcp-windows-latest-webkit

8826 passed, 1480 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

6 flaky

⚠️ [chromium-library] › library/video.spec.ts:356 › screencast › should work for popups `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:113 › screencast › should capture static page `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`

52382 passed, 1243 skipped

---

Merge workflow run.

[github-actions]

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

🟡 Probably unrelated, but two failures have no prior failure history

All three failures are in the MCP suite and each fails on only one bot. idle-timeout on Firefox is a known flake. I found no earlier failures of the other two on the same project, so I can't call them flakes yet. This PR reverts page.webmcp and its hook-up in the MCP Tab. That code is gone on every browser, yet these tests pass on all the other bots in this run.

Details

Checked against the test-results DB snapshot. The update step returned a GitHub API 500, so the last few hours of runs are missing from the counts. Head sha 0d7cf92, MCP run. The "tests 1" report has flaky tests only, no failures.

Pre-existing flake / infra

• [firefox] › mcp/idle-timeout.spec.ts:19 › closes the browser after the idle timeout and relaunches it on the next call (mcp-windows-latest-firefox). Fails with Target page, context or browser has been closed. This test on this project failed in 9 of 880 runs in the DB. Those runs include main (run) and PRs feat(chromium): roll to r1247 #42915, chore(server): remove unused noAutoWaiting action option #42901, test(mcp): work around Chromium losing WebMCP tools in same-origin iframes #42888 and fix(clock): make Temporal.Now follow page.clock #42838, all on the same Windows Firefox bot.

Uncertain

• [webkit] › mcp/annotate.spec.ts:386 › should cancel browser_annotate when the MCP request is aborted (mcp-windows-latest-webkit). Times out waiting for the Dashboard: annotate region. The same test flakes regularly on other projects: Firefox had 13 of 725 runs with a failed attempt, msedge 4, chrome 3, including main. On webkit it has passed all 738 runs in the DB. The annotate/dashboard flow doesn't touch WebMCP, so this is likely a flake, but I found no WebKit failure to prove it. A rerun would settle it.
• [chrome] › mcp/console.spec.ts:435 › browser_console_messages all option for page errors (mcp-macos-latest-chrome). Fails with McpError: MCP error -32000: Connection closed, which means the MCP server process went away mid-test. The test has passed in every one of the roughly 3,600 runs in the DB across chrome, chromium, msedge, firefox and webkit. The revert removes page.webmcp.enable() and the toolschanged listener from Tab._initialize(). That runs for every MCP test on every browser, and this test passes on all other bots in this run, so a single macOS Chrome crash from the revert seems unlikely. That's still a guess. A rerun, or the server's stderr in the job log, would tell.

_{Triaged by the Playwright bot - agent run}