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
In the meeting it was mentioned that some stream methods required workers, which aren't in the minimum common API, and aren't planned to be added since runtimes like Cloudflare Workers won't support them. It seems like any specified cross-agent interactions should not apply to any runtime that doesn't support cross-agent transferring; and for the rest, we could mark a subset of tests as needing the Worker API in order to run (for example, by polyfilling it on top of worker_threads as Node.js does in its WPT runner).
That said, this came up for the transferable stream tests, and transferring can be done with structuredClone without needing another agent. We should see which of those tests are specific to cross-agent interactions, and whether any can be replaced with structuredClone.
As for FileReader, my understanding is that a lot of those tests were written before the stream/text/arrayBuffer/bytes methods existed, so they can probably be updated to use those.
Interestingly, while we don't support the web workers API, Cloudflare Workers does support a form of transferring streams across worker-like boundaries in our jsrpc mechanism. Basically we can do things like env.FOO.doSomething(readable) where doSomething(...) is an RPC call to a different worker (running a different isolate) and the readable is a ReadableStream. For that ReadableStream the observable effect of this should be the same as postMessage(...)ing that ReadableStream to a web worker. Given that, I wonder if there's some way of abstracting exactly how these tests handle the transfer.
Ironically, tho, we don't actually support using structuredClone() to transfer streams even within the same isolate. That's something we can likely add fairly easily tho.
It seems like that PR might not be able to land until there's interest from browsers in shipping ShadowRealm. We might need to make a new PR with the subset of changes that's needed for the minimum common API (e.g. Blob tests can stay, since they're exposed in the mcAPI but not in ShadowRealm) and land that first.
I've been reviewing the sets of tests listed in this issue, and I'd like to propose excluding at a minimum the following tests, which either are designed to test browser features not included in the minimum common api, or if there's something in them that might be relevant, would need to be completely rewritten to work in minimum common api runtimes:
Activity
andreubotella commentedon Mar 21, 2025
This is great! A couple comments:
worker_threadsas Node.js does in its WPT runner).structuredClonewithout needing another agent. We should see which of those tests are specific to cross-agent interactions, and whether any can be replaced withstructuredClone.FileReader, my understanding is that a lot of those tests were written before thestream/text/arrayBuffer/bytesmethods existed, so they can probably be updated to use those.jasnell commentedon Mar 21, 2025
Interestingly, while we don't support the web workers API, Cloudflare Workers does support a form of transferring streams across worker-like boundaries in our jsrpc mechanism. Basically we can do things like
env.FOO.doSomething(readable)wheredoSomething(...)is an RPC call to a different worker (running a different isolate) and thereadableis aReadableStream. For thatReadableStreamthe observable effect of this should be the same aspostMessage(...)ing thatReadableStreamto a web worker. Given that, I wonder if there's some way of abstracting exactly how these tests handle the transfer.Ironically, tho, we don't actually support using
structuredClone()to transfer streams even within the same isolate. That's something we can likely add fairly easily tho.lucacasonato commentedon May 1, 2025
Structured Clone
structuredCloneMore analysis needed: to be done by @andreubotella. web-platform-tests/wpt#49282
DOMException
DOMExceptionWASM
WebAssemblyWe need to write some dedicated tests for wasm structured clone that do not involve DOM / HTML.
navigator
navigatorNo existing tests that we can use.
Create a new test for just
user-agentto check it's a string. maybe also check thatfetchsets theuser-agenttest.performance.now
performance.nowqueueMicrotask
queueMicrotasksetInterval/setTimeoutsetIntervalclearIntervalsetTimeoutclearTimeoutatob/btoaatobbtoalucacasonato commentedon May 2, 2025
Node expectations for fetch: https://github.com/nodejs/undici/blob/main/test/wpt/status/fetch.status.json
<
andreubotella commentedon May 9, 2025
It seems like that PR might not be able to land until there's interest from browsers in shipping ShadowRealm. We might need to make a new PR with the subset of changes that's needed for the minimum common API (e.g.
Blobtests can stay, since they're exposed in the mcAPI but not in ShadowRealm) and land that first.andreubotella commentedon May 15, 2025
FormData(
constructor.any.jsdepends on what we decide to do with the arguments, see #63)Ms2ger commentedon Dec 15, 2025
I've been reviewing the sets of tests listed in this issue, and I'd like to propose excluding at a minimum the following tests, which either are designed to test browser features not included in the minimum common api, or if there's something in them that might be relevant, would need to be completely rewritten to work in minimum common api runtimes: