v158 · webtransport · concurrency hints
Does this build read the hint?
No server needed. A WebTransportOptions dictionary is read synchronously at construction, so an options bag whose members are getters that throw reports exactly which members this build knows about — including the two new concurrency hints — before any network work begins.
Chrome ships these hints enabled by default in Chrome 158. On an earlier build, run Chrome with --enable-blink-features=WebTransportAnticipatedConcurrentIncomingStreams, or flip chrome://flags/#enable-experimental-web-platform-features and relaunch.
Which members does this build read?
Running…
| member | read? | what that means |
|---|
The control rows make the rest trustworthy. serverCertificateHashes has been in the dictionary since WebTransport shipped, so its getter must fire; definitelyNotAMember is invented, so it must not. If either control comes out wrong, no other row here means anything.
The attribute half
The feature also adds the same two names as read-write attributes on the instance, so a hint can be raised mid-session. Attributes need no probe — the prototype simply has them or does not. Here is WebTransport.prototype in this browser, with both hint attributes highlighted if present:
code path
// A getter that throws turns "was this member read?" into a question the
// constructor answers immediately, with no dependence on the return value.
function reads(member) {
const sentinel = "PROBE_" + member;
try {
new WebTransport("https://127.0.0.1:44443/never", {
get [member]() { throw new Error(sentinel); },
});
return false; // never read
} catch (error) {
return error.message === sentinel; // read, and it was our throw
}
}
// The attribute half needs no probe at all.
const proto = WebTransport.prototype;
const hasUni = "anticipatedConcurrentIncomingUnidirectionalStreams" in proto;
const hasBidi = "anticipatedConcurrentIncomingBidirectionalStreams" in proto;