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.
