LGTM1 On Fri, Oct 30, 2026 at 2:54 PM 'Viktoriya Bryhider' via blink-dev < [email protected]> wrote:
> 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/45edd3e5-5fd8-4255-b3a4-47131e792a03n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45edd3e5-5fd8-4255-b3a4-47131e792a03n%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/CAARdPYf%2B6tauqu0Rbj8JxrKL1RLTpU1YzYS2dcf7vzV%3Db_NzmQ%40mail.gmail.com.
