LGTM3 On Wednesday, November 4, 2026 at 8:33:07 AM UTC-8 Daniel Bratell wrote:
> Or make that LGTM2 > > /Daniel > On 2026-11-04 17:31, Daniel Bratell wrote: > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/94ecf84c-bd7a-4689-b9f5-d5673c08d177n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- 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/c108f9bd-eff8-4eee-bc92-5ce39d19e923n%40chromium.org.
