| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
async function waitForTool(name) {This duplicates waitForTool in third_party/blink/web_tests/fast/webmcp/resources/webmcp-helpers.js ...
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Looks like a rebaseline is needed for a bunch of WPTs because of the deprecation warning 😋
Looks like a rebaseline is needed for a bunch of WPTs because of the deprecation warning 😋
Think I got them all. We'll see if the bots are happy.
This duplicates waitForTool in third_party/blink/web_tests/fast/webmcp/resources/webmcp-helpers.js ...
Yeah so there is some unfortunate duplication, there are three `webmcp-helpers.js` files:
- fast/
- wpt_internal
- external/wpt
The duplication between the first two is what you're commenting on, but I don't think those two types of tests can share files, so it is what it is. The last two technically don't have to be duplicated, so I've removed `wpt_internal/webmcp/resources/webmcp-helpers.js` and updated the internal WPTs to reference the external file. Seems like a good change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
Jetski botched the rebase but I fixed it...
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Thanks for cleaning up the duplicate helper script 👍
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Exportable changes to web-platform-tests were detected in this CL and a pull request in the upstream repo has been made: https://github.com/web-platform-tests/wpt/pull/60158.
When this CL lands, the bot will automatically merge the PR on GitHub if the required GitHub checks pass; otherwise, ecosystem-infra@ team will triage the failures and may contact you.
WPT Export docs:
https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#Automatic-export-process
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
*document, window->GetTaskRunner(TaskType::kUserInteraction));I'm officially out of my depth on Chromium's internals here—should we be using `document->GetTaskRunner(...)` instead of using `window`?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
I'm officially out of my depth on Chromium's internals here—should we be using `document->GetTaskRunner(...)` instead of using `window`?
There's no difference in this case. Here we get it the task from LocalDOMWindow, and Document::GetTaskRunner() gets it from its `execution_context_`, which [is a LocalDOMWindow](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.h;l=2714-2721;drc=6a3eac9c665a23caf101edf535b0a3479e5f0b2e). Good question though.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
*document, window->GetTaskRunner(TaskType::kUserInteraction));Dominic FarolinoI'm officially out of my depth on Chromium's internals here—should we be using `document->GetTaskRunner(...)` instead of using `window`?
There's no difference in this case. Here we get it the task from LocalDOMWindow, and Document::GetTaskRunner() gets it from its `execution_context_`, which [is a LocalDOMWindow](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.h;l=2714-2721;drc=6a3eac9c665a23caf101edf535b0a3479e5f0b2e). Good question though.
Thank you for the pointer! I guess the only advantage then would be that we don't have to check for `document->domWindow()` right?
```cpp
ModelContext* ModelContextSupplement::modelContext() {
if (!model_context_) {
Document* document = GetSupplementable();
CHECK(document);
model_context_ = MakeGarbageCollected<ModelContext>(*document);
}
return model_context_.Get();
}
```
And then update ModelContext constructor to set task_runner_ directly from document?
```cpp
ModelContext::ModelContext(
Document& document)
: document_(document),
task_runner_(document.GetTaskRunner(TaskType::kUserInteraction)),
...
```
Does it make sense as a follow up?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
8 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: third_party/blink/web_tests/external/wpt/webmcp/imperative/exposedTo-invalid-origins.https.html
Insertions: 2, Deletions: 2.
@@ -24,8 +24,8 @@
{success: true, origin: 'http://localhost:3000'},
];
- for (const origin of invalid_origins) {
- assert_throws_dom('SecurityError', () => {
+ for (const test of test_cases) {
+ const register = () => {
document.modelContext.registerTool({
name: 'test_tool_' + Math.random(),
description: 'Test tool',
```
WebMCP: Expose document.modelContext
Per https://github.com/webmachinelearning/webmcp/issues/173 and
https://github.com/w3ctag/design-reviews/issues/1231#issuecomment-4502765330,
we're moving `modelContext` to `document` from `navigator`. This CL does
that, but keeps `navigator` exposure around for a bit and dispatches a
console warning when it is used.
This CL also updates all web platform tests to use
`document.modelContext`. There might be other lingering tests elsewhere,
but we can update those when we fully remove the API.
R=mfoltz
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
*document, window->GetTaskRunner(TaskType::kUserInteraction));Dominic FarolinoI'm officially out of my depth on Chromium's internals here—should we be using `document->GetTaskRunner(...)` instead of using `window`?
FrThere's no difference in this case. Here we get it the task from LocalDOMWindow, and Document::GetTaskRunner() gets it from its `execution_context_`, which [is a LocalDOMWindow](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.h;l=2714-2721;drc=6a3eac9c665a23caf101edf535b0a3479e5f0b2e). Good question though.
Thank you for the pointer! I guess the only advantage then would be that we don't have to check for `document->domWindow()` right?
```cpp
ModelContext* ModelContextSupplement::modelContext() {
if (!model_context_) {
Document* document = GetSupplementable();
CHECK(document);
model_context_ = MakeGarbageCollected<ModelContext>(*document);
}
return model_context_.Get();
}
```And then update ModelContext constructor to set task_runner_ directly from document?
```cpp
ModelContext::ModelContext(
Document& document)
: document_(document),
task_runner_(document.GetTaskRunner(TaskType::kUserInteraction)),
...
```Does it make sense as a follow up?
Seems like a good idea, thanks! I've uploaded https://crrev.com/c/7871892
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The WPT PR for this CL has been merged upstream! https://github.com/web-platform-tests/wpt/pull/60158
THE ui was improved
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |