LGTM3. Exciting to see these APIs getting so much attention. On Wednesday, November 4, 2026 at 8:28:50 AM UTC-8 Chris Harrelson wrote:
> 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/7397351b-b362-43b1-aa68-6864f936ce76n%40chromium.org.
