Repository navigation
Scope ModelContext to Document, and handle detached documents - #177
Merged
Merged
Conversation
domfarolino
commented
May 15, 2026
ModelContext lifetime to Document and handle detached documents
ModelContext lifetime to Document and handle detached documentsModelContext to Document, and handle detached documents
bwalderman
requested changes
May 18, 2026
bwalderman
approved these changes
May 18, 2026
github-actions Bot
added a commit
that referenced
this pull request
May 19, 2026
SHA: 986f461 Reason: push, by domfarolino Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This was referenced Aug 21, 2026
rgarcia
added a commit
to kernel/kernel-images
that referenced
this pull request
Sep 28, 2026
) ## Summary Sites that shipped WebMCP tools before Chromium exposed the native registry install their own polyfill on `navigator.modelContext`. Chromium 150 deprecated that alias and later removed it in favor of `document.modelContext` (spec: webmachinelearning/webmcp#177). A polyfill that does not forward to the native registry is invisible to the CDP WebMCP domain, so `GET /webmcp/tools` and `webmcp.listTools()` list nothing even though `await navigator.modelContext.listTools()` shows the tools in page context. This change copies those tools into the frame's native `document.modelContext` registry. From there the CDP WebMCP domain lists, invokes, and removes them like any other page tool; the API and result shapes are unchanged. - On every tool listing, `webmcpclient` syncs a bridge (`polyfill_bridge.js`) in the main world of each tracked frame. Root frames are reached through their session; same-process child frames through the owner element's `contentWindow`. - The bridge is created with `Runtime.callFunctionOn` and is reachable only through the client's remote object handle, so no globals or prototypes change on the page, and neither `Runtime.enable` nor `DOM.enable` is used. Pages that call `document.modelContext.getTools()` do see the bridged tools, the same as custom page tools today. - Each sync registers new polyfill tools, unregisters removed or changed ones, and resets when a same-origin child frame navigates. Bridged tools register under a reserved `polyfill.` prefix, which discovery strips, so they never occupy a name the page may register natively later. When the page registers a name natively, before or after bridging, the native tool is listed and the bridge withdraws its copy on the next sync. A `navigator.modelContext` that is the native registry itself is skipped. - Recognized polyfill conventions: `listTools()` / `getTools()` (array or `{tools}`), registries on `_registeredTools`, `_tools`, `tools`, or `window.__webmcp.tools`, and execution through a registry entry's `execute`, `callTool(name, input)`, `callTool({name, arguments})`, or `executeTool(name, json)`. Metadata is copied as JSON with per-tool, total-list, and output size bounds. - `browsersurface` now records which session owns each frame and exposes `Tracker.SessionFrames`. - A page tool that throws now reports its message in `error_text`. Chromium attaches the thrown value to `WebMCP.toolResponded` as `exception` and leaves `errorText` empty; the client previously dropped it for every page tool. - Tool references are released by registered name when a document goes away, so a replaced document never reuses a stale reference for a prefixed (custom or bridged) tool. ## Testing - `go test -race ./lib/webmcpclient/ ./lib/browsersurface/ ./cmd/api/api/`: fake-CDP tests cover bridging into root, same-process child, and out-of-process frames, bridge reuse, unregistration, recreation for a new document, native precedence and fallback, invocation under the registered name, exception text, and that `Runtime.enable` / `DOM.enable` are never sent. - `node --test runtime/webmcp-polyfill.test.ts` and `make runtime-typecheck`: runs the bridge against site-style, MCP-style, and registry-only polyfills, native collisions, malformed entries, output bounds, and document replacement. - `TestPlaywrightExecuteAPI` e2e against a locally built headless image: the existing declarative and custom subtests plus the new `WebMCPPolyfill` subtest (late-installing polyfill, `srcdoc` child frame, native precedence, a native registration of a bridged name after bridging, thrown-error text, unregistration, navigation, stale refs). --------- Co-authored-by: rgarcia <72655+rgarcia@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR does two things:
ModelContextobject toDocumentinstead ofNavigator, and explains why.modelContextattribute return null when the document is detached (by checking when the Window's browsing context is null). This matches the behavior of thecontentWindowandcontentDocumentgetters—return nothing, even if those objects are allocated and kept alive by other references, in the detached document case.Note that this PR does not handle the "document not fully active" case, which covers detached documents and documents in the bf-cache. Non-fully active documents probably shouldn't impact the
modelContextgetter—it seems weird for getters like that to return different values based on whether the document is in the bf-cache—but rather need special behavior in theregisterTool()method, and the cominggetTools()andexecuteTool()methods.This PR mostly addresses #173, with the exception of considering moving the API to
self, fromnavigator. As much as I want to do this, I'm sympathetic to w3ctag/design-principles#426 (comment), so for now I'm leaning towards not moving it. So I'll say that this PR closes #173.Preview | Diff