You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: MCP page-registered WebMCP tools stay bound to a stale frame or tab when the tool list looks unchanged #42816
browser_tabs { action: "select", index: 0 } (current tab is now /one)
webmcp_whoami {}
Expected behavior
A. The call after the reload runs against the new frame and succeeds.
B. The tool runs in the selected tab and returns tab-one.
Actual behavior
A: ### Error
browserBackend.callTool: Frame was detached
B: ### Result
Called WebMCP tool "whoami" in http://localhost:PORT/two ... "text": "tab-two"
The tool is still listed after the reload but cannot be called, and in the two-tab case a page tool silently runs in the non-current tab, which is a wrong-target execution for consequential tools such as "place order" or "send message".
Additional context
Context.maybeNotifyWebMCPToolsChanged() (packages/playwright-core/src/tools/backend/context.ts) compares JSON.stringify(tools.map(t => t.schema)) against the previous signature and returns early when equal, keeping the old _webmcpTools. Each WebMCPToolDefinition.handle is a closure over the Tab and Frame captured when the listing was taken (webmcp.ts, toMcpToolDefinition). A reload recreates child frames, and switching between two tabs with identical tools produces an identical signature, so the stale closures are kept while the schema looks unchanged.
Suggested fix: always replace _webmcpTools with the fresh definitions and only gate the listChanged notification on the schema signature.
I intend to work on this and will send a PR.
Environment
- Operating System: macOS (Darwin 25.6.0)
- Node.js: 24.8.0
- Browser: Google Chrome with --enable-features=WebMCP
- Playwright: main @ 07f1a6154
The distinction between the schema signature and the executable binding is important here. I would keep the notification optimization, but rebuild the definitions whenever the observed frame/tab context changes—even when the tool schemas are byte-for-byte identical.
A focused regression matrix could cover:
same iframe tool after reload: the new frame executes, with no detached-frame error;
identical tool name/schema in two tabs: selecting tab A then calling the tool can only execute in tab A;
same-schema navigation, popup/active-tab change and frame replacement;
a dispatch racing tab selection or frame detachment: reject with a typed stale-target/target-changed result rather than silently running in the previously captured context.
The definition can carry a non-user-facing binding generation (page/tab/frame identity plus navigation generation) while listChanged remains schema-based. At dispatch, compare that binding with the selected/current target and invalidate on drift. That makes a page-declared consequential tool behave like a request bound to a browser context, not just a schema entry.
I maintain Hronaut, a local visible Browser/MCP workspace, and this is a general browser-authority observation rather than a Hronaut/WebMCP compatibility claim. Prepared with AI assistance.
Activity
Hronom commentedon Sep 21, 2026
The distinction between the schema signature and the executable binding is important here. I would keep the notification optimization, but rebuild the definitions whenever the observed frame/tab context changes—even when the tool schemas are byte-for-byte identical.
A focused regression matrix could cover:
The definition can carry a non-user-facing binding generation (page/tab/frame identity plus navigation generation) while listChanged remains schema-based. At dispatch, compare that binding with the selected/current target and invalidate on drift. That makes a page-declared consequential tool behave like a request bound to a browser context, not just a schema entry.
I maintain Hronaut, a local visible Browser/MCP workspace, and this is a general browser-authority observation rather than a Hronaut/WebMCP compatibility claim. Prepared with AI assistance.
chore: mark v0.0.83 (#1779)
chore: mark v0.1.22 (#473)
chore(deps): update all non-major dependencies (#199)
chore(deps): update dependency @playwright/mcp to v0.0.83 (#1108)
chore: mark v0.0.83 (microsoft#1779)
Update agent CLIs