WPT analysis

[lucacasonato]

AbortSignal

• AbortController
• AbortSignal

+dom/abort/*
-dom/abort/reason-constructor.html

Web Crypto API

• Crypto
• CryptoKey
• SubtleCrypto
• globalThis.crypto

+WebCryptoAPI/*
-historical.any.*
-algorithm-discards-context.https.window.*

Console

• globalThis.console

+console/*

Tests are very sparse, and so is spec - it is unclear what side-effects console.log should have across runtimes.

Streams

• ByteLengthQueuingStrategy
• CountQueuingStrategy
• ReadableByteStreamController
• ReadableStream
• ReadableStreamBYOBReader
• ReadableStreamBYOBRequest
• ReadableStreamDefaultController
• ReadableStreamDefaultReader
• TransformStream
• TransformStreamDefaultController
• WritableStream
• WritableStreamDefaultController
• WritableStreamDefaultWriter

+streams/*
-streams/readable-streams/cross-realm-crash.window.html

streams/transferable/* needs investigation.

(De)compression streams

• CompressionStream
• DecompressionStream

+compression/*

Text encoding

• TextDecoder
• TextDecoderStream
• TextEncoder
• TextEncoderStream

+encoding/*
-encoding/streams/realms.window.html
-encoding/streams/invalid-realm.window.html
-encoding/unsupported-encodings.any.*
-encoding/single-byte-decoder.window.html
-encoding/unsupported-labels.window.html

URL

• URL
• URLSearchParams

+url/*
-url/url-setters-a-area.window.html
-url/a-element-origin.html
-url/a-element.html
-url/data-uri-fragment.html
-url/failure.html

Note, a lot of tests in this directory also test using <a> and <area> tags from HTML. It would be good to split those into seperate files.

URLPattern

• URLPattern

+urlpattern/urlpattern.any.*
+urlpattern/urlpattern-https.any.*
+urlpattern/urlpattern-hasregexpgroups.any.*

File API

• Blob
• File

+FileAPI/blob/*
-FileAPI/blob/Blob-constructor-dom.window.html
+FileAPI/file/*
-FileAPI/file/send-file-form-*
+FileAPI/url/url-format.any.*
+FileAPI/url/url-with-fetch.any.*
+FileAPI/unicode.html

A lot of these tests rely on FileReader existing. Should we add this?

[andreubotella]

This is great! A couple comments:

• 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.

[jasnell]

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.