LGTM2 On Mon, Nov 2, 2026 at 3:28 AM Philip Jägenstedt <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf%2B6tauqu0Rbj8JxrKL1RLTpU1YzYS2dcf7vzV%3Db_NzmQ%40mail.gmail.com?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%2Bw98-AZbAcvRJv9mh2%2BTnXtzzYMSWfQRjt_k6nMVeL%2BUmg%40mail.gmail.com.
