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.
