Dominic Farolino
10c764af16
Automatic update from web-platform-tests
WebMCP: 3/3 Cross-origin iframe tool execution and safety hardening
This CL implements cross-origin iframe tool execution via the
`executeTool()` method on the `ModelContext` interface.
Major changes introduced in this CL:
- Introduces the `executeTool()` method on `ModelContext`. To use it,
first you must obtain a `RegisteredTool` dictionary from
`navigator.modelContext.getTools()`. Then, you can pass a tool
directly as the first argument of `executeTool()`:
```
const [tool] = await navigator.modelContext.getTools();
navigator.modelContext.executeTool(tool, args);
```
The contents of `RegisteredTool` are mostly to provide identifiable
information about the tool to invokers; but from the browser's
perspective, the tool's `name` and `window` (which the browser
gets a FrameToken from) are used to uniquely identify the tool.
- Modifies the `RegisteredTool` dictionary definition to expose a tool
host's `Window` and `origin`. The Window/name combination uniquely
identify the tool in the frame tree.
- Introduces a `RegisteredToolDeprecated` reduced dictionary for the
ModelContextTesting API to use, so that legacy interface's surface
area remains unchanged after this CL. This keeps ModelContextTesting
operating narrowly on its own Document, and unconcerned with
cross-document tools.
- Performs tool execution with two new IPCs:
- `ExecuteScriptTool()` on ModelContextHost, for the renderer to
request that the browser invokes a tool in another document. It
locates the tool by the frame token that the caller knows the tool
host by and requests the hosting document to invoke the tool.
- `ExecuteScriptTool()` on ModelContext, for the browser to tell a
renderer that owns a tool to invoke it.
- Both IPCs have callbacks: the latter's callback lets the tool host
gives the tool response to the browser, and the former's callback
lets the browser forward it back to the caller.
- Tracks pending tool executions with `ModelContextPageUserData`
- When a tool is executed, the invoker's callback is stored in this
Page-scoped data structure. Then, when a document hosting a
still-running tool gets destroyed, this data structure is
consulted to reject the Promise in the invoker's document.
For a sense of remaining work that needs to be done for the iframe use
case, see:
- https://crbug.com/509555636
- https://crbug.com/509568047
- https://crbug.com/508306795
- https://crbug.com/508285989
- http://b/481899636
R=mfoltz
Low-Coverage-Reason: COVERAGE_UNDERREPORTED
Bug: 506393880,489045948
Change-Id: Id9de2a9f985da2cf34dac9f626180cfb25a253d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7808168
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1627321}
--
wpt-commits: 32af1ac99fdf58c226ed32014e7bda8e5671b676
wpt-pr: 59740
2 lines
47 B
Plaintext
2 lines
47 B
Plaintext
Content-Security-Policy: sandbox allow-scripts
|