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 Web Feature ID 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? 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 (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, 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. -- 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/6aea5e51.e5ec2bf0.2ba4f6.01ba.GAE%40google.com.
