Automatic update from web-platform-tests
WebMCP: Queue declarative tool registration and schema calculation
Before this CL, declarative WebMCP tools were registered synchronously,
but had their JSON schemas computed lazily, upon (legacy) `listTools()`
invocation, etc. Tool registration looked like this:
1. When a form with `toolname` and `tooldescription` was inserted, it
synchronously registered a tool with `ModelContext` with an empty
schema
2. A task was queued to fire the `toolchange` event at both
modelContext and modelContextTesting.
3. The `RegisterScriptTool()` IPC is sent to the browser;
asynchronously later, it sends `NotifyToolChange()` to tell the
renderer to fire the `toolchange` event (again!)
4. As form control elements become associated or mutate, the same
underlying tool is left alone, but a task is queued to:
1. Fire `toolchange` events
2. Tell DevTools that the tool has been removed/re-added
The two above only happen if the control association/mutation is
deemed to impact the tool's inputSchema.
So declarative tools are never unregistered as they get built up and as
their schemas change, and `toolchange`/DevTools notifications happen
once per batch of changes.
But right now, the browser process doesn't know how to "update" a tool's
schema, so to keep it "fresh" after schema-affecting mutations, we must
unregister/re-register tools accordingly (later we could consider an
"update" path in the browser process).
To accomplish this, the CL does a few things:
- Instead of registering declarative tools immediately with an empty
schema but queueing a `toolchange` event, this CL queues the
registration of the form altogether. That way by registration time,
batched mutations are done, and the form's schema can be computed
once at the end.
- When form controls become associated or mutate, they unregister and
re-register the underlying form tool if it impacts the existing
tool's schema. Before this CL, they just queued a `toolchange` event
if the schema was impacted.
Performing schema diffs at unregistration/registration time allows us to
delete:
- ModelContext::OnToolChange(bool force);
- ModelContext::InvokeToolChangeClosure(bool force);
- ModelContext::MaybeNotifyToolChanged();
This also makes declarative tools play nicely with the new `getTools()`
and `executeTool()` APIs introduced in https://crrev.com/c/7800264 and
https://crrev.com/c/7808168, because with those APIs.
Concretely, this CL:
- Introduces a new TaskHandle for the async task on HTMLFormElement
- Adds an `HTMLFormElement::ChildrenChanged()` handler which queues the
tool registration task, so that once form mutations settle, the
queued task has a full picture of the form and its JSON schema.
- Renames `UpdateMcpDefinitionsIfNeeded()` to
`ScheduleDeclarativeWebMCPToolRegistration()`, which does the
scheduling.
- Introduces `RegisterDeclarativeWebMCPTool()` which does the actual
registration and input schema diffing.
- Updates `ScheduleWebMCPSchemaUpdate()` (called for each new
form control association/attr change) to call
`ScheduleDeclarativeWebMCPToolRegistration()`, if the form has a
registered tool.
To make this work, this CL modifies a bunch of declarative WebMCP tests
to make them wait on `toolchange` being fired before accessing the tool.
R=masonf
Bug: 502363131
Change-Id: I1b933092c9e5e6c023c69172ad961161e647ae99
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7817087
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1630821}
--
wpt-commits: 987f7d83b127a065b2e9b408021ab13a688edf03
wpt-pr: 59889
Dominic Farolino
c0ebe6ddc2