LGTM1 /Daniel
On Tuesday, 3 November 2026 at 23:21:22 UTC+1 Chromestatus wrote: > *Contact emails* > [email protected] > > *Explainer* > https://github.com/w3c/webtransport/blob/main/explainer.md > > *Specification* > https://www.w3.org/TR/webtransport/#web-transport-error-interface > > *Design docs* > > https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError > https://developer.chrome.com/docs/capabilities/web-apis/webtransport > > *Summary* > Updates Chromium WebTransportError to match the current WebTransport > specification. Adds the standard (message, options) constructor while > preserving the shipped dictionary constructor for compatibility; carries > the full unsigned-long stream error code end to end; and makes > WebTransportError structured-clonable while preserving its message, source, > and nullable error code. Serialization is enabled by default behind a > writer-side runtime kill switch, while decoding remains permanently enabled > for persisted values. > > *Blink component* > Blink>Network>WebTransport > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> > > *Web Feature ID* > webtransport <https://webstatus.dev/features/webtransport> > > *Motivation* > Chromium's shipped WebTransportError implementation predates the current > WebTransport specification. It accepts a legacy dictionary-only > constructor, narrows outgoing application stream error codes to 8 bits > despite the API exposing an unsigned long, and does not support the > structured serialization required by the specification. The change aligns > Chromium with the standardized API and improves WebTransport > interoperability. The legacy constructor remains available so existing > Chromium applications continue to work. > > *Initial public proposal* > *No information provided* > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/669 > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > Interoperability risk Low. The constructor, WebTransportErrorOptions > dictionary, unsigned-long streamErrorCode, source attribute, and > serialization behavior are defined in the W3C WebTransport specification > and covered by Web Platform Tests. Mozilla implemented the same constructor > and full-width stream error-code behavior and contributed the relevant WPT > coverage: https://github.com/web-platform-tests/wpt/pull/63842 > Compatibility risk Low. Chromium's shipped dictionary constructor is > retained as a compatibility overload, including its existing octet clamping > and handling of trailing arguments. Existing calls therefore continue to > work. The intentional behavior changes are that application stream error > codes above 255 are no longer truncated, and structured-cloning a > WebTransportError now succeeds instead of throwing DataCloneError. Code > that deliberately depended on either non-standard behavior could observe a > difference. > > *Gecko*: Shipped/Shipping ( > https://bugzilla.mozilla.org/show_bug.cgi?id=2009530) > > *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=305224 > ) > > *Web developers*: Positive ( > https://github.com/web-platform-tests/interop/issues/1121) The Interop > 2026 WebTransport proposal received 28 👍 reactions. Developers also > reported active WebTransport use and significant cross-engine differences. > > *Other signals*: > > *Ergonomics* > Low. The standard constructor follows familiar Error and DOMException > patterns: new WebTransportError("message", { source: "stream", > streamErrorCode: 70000 }); Existing Chromium dictionary-style construction > remains supported. Structured cloning preserves the WebTransportError > subtype and its WebTransport-specific properties instead of reducing it to > a generic exception or rejecting it. > > *Activation* > Low. The standard constructor and full-width stream error-code support > correct existing non-conforming behavior while preserving Chromium's legacy > constructor. Structured serialization is newly observable behavior. It is > controlled by the WebTransportErrorSerialization runtime feature, which is > enabled by default but retained as a writer-side kill switch. The > deserializer is intentionally always enabled so WebTransportError values > already stored in IndexedDB or other structured-clone storage remain > readable if writing is disabled. The implementation is covered by focused > Blink and Network Service tests and the Mozilla Web Platform Tests. > > *Security* > Low. The change does not grant additional network access, expose new > server or user information, or weaken WebTransport's secure-context > requirement. Structured cloning copies only the WebTransportError subtype, > DOMString message, source enum, and nullable unsigned 32-bit stream error > code. The versioned decoder validates the format version, enum > discriminants, presence flags, string code units, and payload completeness > before constructing an object. > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > Low risk. This aligns the existing WebTransportError API with the current > specification. Existing error values from 0–255 retain identical behavior, > the legacy constructor remains supported, and ordinary creation, throwing, > and catching are unchanged. Structured cloning changes from throwing > DataCloneError to succeeding. Serialization writes are protected by a kill > switch, while the reader remains enabled for compatibility with previously > persisted data. > > > *Debuggability* > No feature-specific DevTools support is required. Developers can inspect > WebTransportError.name, message, source, and streamErrorCode in the > DevTools Console. Existing WebTransport diagnostics, NetLog, Network > Service logging, and QUIC logging remain available for tracing the > underlying stream error. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > > https://wpt.fyi/results/webtransport/idlharness.https.sub.any.html?label=experimental&label=master&aligned > > *DevTrial instructions* > https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError#examples > > *Flag name on about://flags* > enable-experimental-web-platform-features > > *Finch feature name* > WebTransportErrorSerialization > > *Non-finch justification* > Ships enabled to 100%. The runtime feature is retained as a serialization > kill switch, not for a gradual Finch experiment. > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/577073049 > > *Measurement* > A Blink UseCounter will measure use of Chromium's legacy dictionary > WebTransportError constructor so that its compatibility impact can be > evaluated before any future deprecation. The standardized constructor, > uint32 stream error-code propagation, and serialization behavior are > validated through WPT and Chromium integration tests. No dedicated UMA > metric is planned for serialization because it is a deterministic > structured-clone capability and does not change network policy or resource > allocation. > > *Availability expectation* > Firefox has implemented the aligned WebTransportError API, including > structured serialization. WebKit supports WebTransport and has landed the > updated constructor and stream error-code behavior, although > WebTransportError-specific structured serialization has not yet been > confirmed. Remaining interoperability is being tracked through Interop 2026. > > *Adoption expectation* > Existing WebTransport applications benefit automatically from the > corrected constructor and full-width stream error codes. Applications using > workers, postMessage(), structuredClone(), or persistent structured-clone > storage can propagate WebTransportError values without custom conversion. > No migration is required for existing users > > *Adoption plan* > Ship the standards-aligned behavior by default, maintain Web Platform Test > coverage, and track cross-browser implementation through the Interop 2026 > WebTransport effort. This is primarily a compatibility and interoperability > correction, so no separate developer migration campaign is necessary. > > *Estimated milestones* > Shipping on desktop 159 > DevTrial on desktop 159 > Shipping on Android 159 > DevTrial on Android 159 > Shipping on WebView 159 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None anticipated. This implements the current WebTransport specification > rather than introducing a new API design. No known open specification > issues are expected to require incompatible changes to this API. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5158277221580800?gate=5546593351761920 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/94ecf84c-bd7a-4689-b9f5-d5673c08d177n%40chromium.org.
