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
<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/f4bc231a-04df-4d8f-a4ea-4255b2ffb74e%40gmail.com.
