LGTM3
On 10/28/26 5:20 a.m., Chris Harrelson wrote:
LGTM2
On Tue, Oct 27, 2026 at 7:03 PM Alex Russell
<[email protected]> wrote:
LGTM1; love to see these practical additions!
On Wednesday, October 21, 2026 at 6:31:37 PM UTC-7 Chromestatus wrote:
*Contact emails*
[email protected]
*Explainer*
https://github.com/w3c/webtransport/issues/372
https://github.com/w3c/webtransport/pull/395
*Specification*
https://w3c.github.io/webtransport/#webtransportreceivestream
*Summary*
Adds the standardized WebTransportReceiveStream interface, a
ReadableStream subclass used for incoming unidirectional
streams and the readable side of bidirectional streams. Its
getStats() method returns per-stream byte counters:
bytesReceived reports bytes received from the network, while
bytesRead reports bytes delivered to the application.
*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*
Incoming WebTransport streams have historically been exposed
as generic ReadableStream objects in Chromium. The
WebTransport specification defines a dedicated
WebTransportReceiveStream subclass with stream-specific
statistics. Applications that receive large or
latency-sensitive streams need to distinguish bytes received
by the browser from bytes actually consumed by JavaScript.
This helps diagnose application backpressure, buffering, and
slow-consumer behavior. Exposing the standardized subclass
also aligns the runtime type of incoming streams with the
WebTransport specification and other browser engines.
*Initial public proposal*
/No information provided/
*TAG review*
/No information provided/
*TAG review status*
Not applicable
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
Enabling this feature changes incoming unidirectional streams
and the readable side of bidirectional streams from plain
ReadableStream objects to WebTransportReceiveStream objects.
Reading remains compatible, and the objects remain instanceof
ReadableStream, but applications that compare the exact
constructor or prototype may observe a change. Firefox and
Safari already expose WebTransportReceiveStream, so this
aligns Chrome’s stream type with those browsers.
/Gecko/: Under
consideration
(https://searchfox.org/mozilla-central/source/dom/webidl/WebTransportSendReceiveStream.webidl)
Partial
implementation. Firefox ships WebTransportReceiveStream and
exposes getStats(), but getStats() currently rejects with
NotSupportedError, so receive stream statistics are not
implemented. Implementation
https://searchfox.org/mozilla-central/source/dom/webtransport/api/WebTransportReceiveStream.cpp
/WebKit/:
Shipped/Shipping (https://commits.webkit.org/300850@main)
WebKit-7624.1.16
implements WebTransportReceiveStream and pipes real
receive-stream statistics through WebCore and the network
process. WebTransport shipped in Safari 26.4. Implementation -
https://github.com/WebKit/WebKit/blob/WebKit-7624.1.16/Source/WebCore/Modules/webtransport/WebTransportReceiveStream.cpp#L54-L65
/Web developers/:
Positive (https://github.com/web-platform-tests/interop/issues/1121) The
Interop 2026 WebTransport proposal received 28 positive
reactions. Developers also reported active WebTransport use
and significant cross-engine differences.
/Other signals/:
*Ergonomics*
getStats() asynchronously returns a snapshot with
bytesReceived and bytesRead. bytesRead is expected to be less
than or equal to bytesReceived. Chromium preserves final
counters when streams finish, are reset or cancelled, or when
the Mojo connection disconnects. The interface is not
constructible directly; applications obtain it from
incomingUnidirectionalStreams or from the readable side of a
bidirectional stream. Chromium's IDL currently types
WebTransportBidirectionalStream.readable as ReadableStream
because Blink cannot conditionally change an IDL attribute
type behind a runtime flag, although the returned object is a
WebTransportReceiveStream when the feature is enabled.
*Activation*
Activation is automatic for sites using incoming WebTransport
streams; no server change or opt-in is required. Existing code
that treats these objects as ReadableStream continues to work
because WebTransportReceiveStream is a subclass. The runtime
type and prototype are observably different, so code that
relies on an exact ReadableStream constructor or prototype
could behave differently. Feature detection using "getStats"
in stream is recommended.
*Security*
The API adds no network capability and exposes no peer
address, credentials, or payload contents. It reports byte
counters for a stream already available to the calling origin.
These values reveal only the amount of data received by the
browser and consumed by that application.
*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. This is an additive API on existing WebTransport streams
and does not change connection establishment or network
behavior. WebView code that does not inspect the stream's
exact runtime type is unaffected.
*Debuggability*
Developers can inspect incoming streams and call getStats()
from the DevTools Console. The returned bytesReceived and
bytesRead values help distinguish network delivery from
application consumption. DevTools does not currently provide a
dedicated per-WebTransport-stream statistics UI.
*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/receive-stream-stats.https.any.html
*Flag name on about://flags*
enable-experimental-web-platform-features
*Finch feature name*
WebTransportReceiveStream
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/568317222
*Availability expectation*
The interface is defined in the W3C WebTransport
specification. WebKit implements WebTransportReceiveStream and
real receive-stream statistics. Firefox exposes
WebTransportReceiveStream, but its getStats() implementation
currently rejects with NotSupportedError. Implementations are
expected to converge through the Interop 2026 WebTransport
focus area.
*Adoption expectation*
Expected to be adopted by WebTransport applications that
monitor per stream throughput, buffering, or slow-consumer
behavior. Code that only reads from incoming streams does not
need to change.
*Adoption plan*
Adoption is expected to occur organically through WebTransport
documentation, examples, and client library support.
Developers can progressively enhance existing code by
feature-detecting getStats().
*Non-OSS dependencies*
Does the feature depend on any code or APIs outside the
Chromium open source repository and its open-source
dependencies to function?
No
*Estimated milestones*
Shipping on desktop 158
DevTrial on desktop 155
Shipping on Android 158
DevTrial on Android 155
Shipping on WebView 158
*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 known for the WebTransportReceiveStream interface or the
bytesReceived and bytesRead members.
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5109912169480192?gate=6063689550659584
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/ca305a97-1ac6-4382-843c-47b096efdc98n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca305a97-1ac6-4382-843c-47b096efdc98n%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/CAOMQ%2Bw_Nw-XvTrHSFQZ2mD9Sb9m47Hbt67iJ1XdhrWfFo0igtg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_Nw-XvTrHSFQZ2mD9Sb9m47Hbt67iJ1XdhrWfFo0igtg%40mail.gmail.com?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/a5197d88-08b4-40cc-a534-8cbf468b2c90%40chromium.org.
