This feature implementation provides the scheduling functionality for sendGroup and sendOrder, which will also help enable WebTransportDatagramsWritable - WebTransport Datagram writable streams and prioritization - Chrome Platform Status <https://chromestatus.com/feature/5183354944225280>.
On Wednesday, October 28, 2026 at 4:34:36 PM UTC-7 Chromestatus wrote: > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> > > *Web Feature ID* > webtransport <https://webstatus.dev/features/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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 (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 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 > <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/08f06477-ac00-48bf-97bf-b40d25d0f60bn%40chromium.org.
