Contact emails [email protected]
Explainer https://github.com/w3c/webtransport/blob/main/explainer.md#6-sending-video-one-stream-per-frame-or-segment-with-send-order https://github.com/w3c/webtransport/blob/main/explainer.md#7-sending-real-time-game-data-per-stream-with-send-order https://github.com/w3c/webtransport/blob/main/explainer.md#8-managing-bandwidth-with-send-groups Specification https://www.w3.org/TR/webtransport/#webtransportsendstream Summary WebTransport already lets sites send data through WritableStreams. This feature lets applications assign outgoing streams to send groups and use sendOrder to prioritize streams within each group. It also provides sending statistics for streams and groups while preserving WritableStream transfer behavior. Blink component Blink>Network>WebTransport Web Feature ID webtransport Motivation Real-time applications often send multiple independent flows over one WebTransport session. When those flows compete for bandwidth, applications need to keep one flow from dominating while deciding which streams within each flow should go first. They also need visibility into sending progress so they can understand how those flows are performing. Initial public proposal No information provided TAG review No information provided TAG review status Not applicable Goals for experimentation None Risks Interoperability and Compatibility Firefox and Safari already expose WebTransportSendStream and the WebTransportSendGroup API; send groups shipped in Firefox 155 and Safari 26.4. Changing Chrome's outgoing streams from plain WritableStream objects to WebTransportSendStream objects therefore aligns their JavaScript type with those browsers. Existing writing behavior and instanceof WritableStream checks remain compatible. Enabling this feature changes outgoing unidirectional streams and the writable side of bidirectional streams from plain WritableStream objects to WebTransportSendStream objects, so exact constructor or prototype check may need updating. Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=2007165) Firefox exposes WebTransportSendStream as a WritableStream subclass for outgoing WebTransport streams, including streams created by createUnidirectionalStream(). It added WebTransportSendGroup and createSendGroup() in Firefox 155, released September 1, 2026; group assignments are passed to its network implementation - https://www.firefox.com/en-US/firefox/155.0/releasenotes/ Firefox does not yet provide equivalent statistics behavior. In its current source, WebTransportSendStream.getStats() rejects with NotSupportedError. WebKit: Shipped/Shipping (https://github.com/mdn/browser-compat-data/blob/main/api/WebTransportSendGroup.json#L52) WebKit implements WebTransportSendGroup, WebTransportSendStream, sendGroup/sendOrder, both statistics methods, transferability, and the specialized writer. Safari 26.4 includes these WebTransport additions. 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 Send groups divide outgoing streams into separate bandwidth-sharing groups; sendOrder prioritizes streams within a group, groups are scheduled separately. Developers could mistake a higher sendOrder for a guarantee of delivery order or throughput. Priority is sender-side scheduling, and flow control and network conditions still affect delivery. Stream and group getStats() return asynchronous snapshots; bytesWritten, bytesSent, and bytesAcknowledged represent different stages of transmission, not interchangeable totals. Outgoing streams remain WritableStream subclasses, so existing writing APIs continue to work. The specialized WebTransportWriter is not part of this launch: getWriter() still returns a WritableStreamDefaultWriter. Activation Enabling the feature changes the runtime type and prototype of outgoing unidirectional streams and the writable side of bidirectional streams from plain WritableStream to WebTransportSendStream for all sites using those streams; sites do not need to call createSendGroup() to observe that change. Code that checks the exact constructor or prototype may behave differently if code assumes exact stream type: stream.constructor === WritableStream or Object.getPrototypeOf(stream) === WritableStream.prototype. Existing stream writes should continue to work, and no server change is needed to use the new client-side priority controls. Transfer of existing send streams must continue working before activation. Security No new network capability or origin boundary is introduced. The API operates only on streams belonging to an existing secure-context WebTransport session. A send group from another WebTransport object is rejected. Statistics expose byte counters for the application's own streams and groups. 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. Debuggability The stream's sendGroup and sendOrder values are directly observable from script. Both stream and group getStats() expose bytesWritten, bytesSent, and bytesAcknowledged; group statistics aggregate streams in that group. DevTools does not currently provide dedicated WebTransport stream inspection, so developers primarily diagnose this API through script and application logging. 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/sendgroup.https.any.html https://wpt.fyi/results/webtransport/sendorder.https.any.html https://wpt.fyi/results/webtransport/sendstream-bad-chunk.https.any.html https://wpt.fyi/results/webtransport/send-stream-stats.https.any.html Flag name on about://flags enable-experimental-web-platform-features Finch feature name WebTransportSendGroup Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://crbug.com/568825278 Availability expectation Firefox 155 ships createSendGroup(), and Safari 26.4 ships WebTransport with the corresponding WebKit group and send-stream interfaces. Chrome shipping would make the API shape available across the major engines. Adoption expectation Adoption is expected mainly among existing WebTransport applications with multiple concurrent streams and latency-sensitive traffic. 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 159 DevTrial on desktop 153 Shipping on Android 159 DevTrial on Android 153 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 known for the WebTransportSendStream or WebTransportSendGroup. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5235261159112704?gate=6451678743232512 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/6ae2867d.4000571a.28172.010c.GAE%40google.com.
