Thanks for the data, Monica. LGTM3. On Wednesday, November 4, 2026 at 8:27:28 AM UTC-8 Philip Jägenstedt wrote:
> LGTM2 > > On Wed, Nov 4, 2026 at 5:24 PM Chris Harrelson <[email protected]> > wrote: > >> LGTM1 >> >> On Wed, Oct 28, 2026 at 11:20 PM 'Monica Chintala' via blink-dev < >> [email protected]> wrote: >> >>> Thanks, Alex. We cannot measure the exact intersection, but existing >>> UseCounters provide an upper bound. Access to WebTransport.datagrams >>> peaked at 0.0126% of page loads over the last 30 days. For the common >>> getReader({mode: "byob"}) pattern, the upper bound is 0.00232%, fewer than >>> 1 in 43,000 page loads. >>> >>> The actual intersection may be lower because the BYOB counter covers all >>> APIs. Affected applications can preserve the current behavior with >>> datagramsReadableType: "bytes", and the change remains Finch-controlled >>> for rollback. >>> >>> On Wednesday, October 28, 2026 at 8:32:01 AM UTC-7 Alex Russell wrote: >>> >>>> Is there an upper bound for potential breakage? Do we have metrics for >>>> total use of datagram readable streams w/ BYOB behaviours? >>>> >>>> On Wednesday, October 28, 2026 at 7:35:15 AM UTC-7 Monica Chintala >>>> wrote: >>>> >>>>> We don’t have a metric for this exact usage pattern. The affected case >>>>> is limited to applications requesting a BYOB reader without opting into >>>>> "bytes". >>>>> >>>>> Default readers continue to work unchanged. Applications using BYOB >>>>> can preserve the existing Chromium behavior by adding: >>>>> {datagramsReadableType: "bytes"} >>>>> >>>>> This option can be added before rollout and works with both the old >>>>> and new behavior. Firefox and Safari stable already use the new default. >>>>> The rollout is Finch-controlled, so we can restore the previous default >>>>> without a new release if compatibility problems are reported. >>>>> >>>>> On Tuesday, October 27, 2026 at 12:02:26 PM UTC-7 Alex Russell wrote: >>>>> >>>>>> What's the potential for breakage, given that we're changing default >>>>>> behavior? Do our histograms tell us the fraction of pageloads that would >>>>>> be >>>>>> affected? >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Wednesday, October 21, 2026 at 1:52:53 PM UTC-7 Chromestatus wrote: >>>>>> >>>>> *Contact emails* >>>>>>> [email protected], [email protected] >>>>>> >>>>>> >>>>>>> >>>>>>> *Explainer* >>>>>>> https://github.com/w3c/webtransport/blob/main/explainer.md >>>>>>> >>>>>>> *Specification* >>>>>>> >>>>>>> https://www.w3.org/TR/webtransport/#dom-webtransportoptions-datagramsreadabletype >>>>>>> >>>>>>> >>>>>>> *Summary* >>>>>>> Adds the WebTransportOptions.datagramsReadableType constructor >>>>>>> option. By default, incoming WebTransport Datagrams are exposed through >>>>>>> a >>>>>>> default ReadableStream . Applications that require BYOB reading can >>>>>>> request a readable byte stream by setting datagramsReadableType: >>>>>>> "bytes" . >>>>>>> >>>>>>> *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* >>>>>>> WebTransport Datagrams are discrete messages rather than an >>>>>>> undifferentiated byte sequence. A readable byte stream can lose empty >>>>>>> Datagrams and can lose message boundaries when BYOB reads use a minimum >>>>>>> byte count spanning multiple Datagrams. Making a default >>>>>>> ReadableStream >>>>>>> the default preserves Datagram boundaries and empty Datagrams. >>>>>>> Applications >>>>>>> that benefit from BYOB allocation control can explicitly opt into the >>>>>>> byte-stream behavior. >>>>>>> >>>>>>> *Initial public proposal* >>>>>>> *No information provided* >>>>>>> >>>>>>> *TAG review* >>>>>>> Not applicable — this is a small incremental addition within the >>>>>>> existing WebTransport specification. >>>>>>> >>>>>>> *TAG review status* >>>>>>> Not applicable >>>>>>> >>>>>>> *Goals for experimentation* >>>>>>> None >>>>>>> >>>>>>> *Risks* >>>>>>> >>>>>>> >>>>>>> *Interoperability and Compatibility* >>>>>>> Interoperability risk is low to medium. The API and default-stream >>>>>>> behavior are defined in the WebTransport specification and covered by >>>>>>> WPT. >>>>>>> Firefox already uses a default non-byte stream when the option is >>>>>>> omitted, >>>>>>> but does not yet support the explicit "bytes" mode in current public >>>>>>> test >>>>>>> runs. Compatibility risk is mitigated by runtime gating. Chromium >>>>>>> historically exposed the Datagram readable as a byte stream, so >>>>>>> enabling >>>>>>> the feature changes the default behavior: existing applications using a >>>>>>> BYOB reader without specifying datagramsReadableType: "bytes" would >>>>>>> fail. >>>>>>> Applications using ordinary readers continue to receive Uint8Array >>>>>>> chunks >>>>>>> >>>>>>> *Gecko*: Positive ( >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=2007755) Firefox is >>>>>>> implementing datagramsReadableType: "bytes" and BYOB Datagram reads >>>>>>> >>>>>>> *WebKit*: In development ( >>>>>>> https://bugs.webkit.org/show_bug.cgi?id=319830) WebKit main >>>>>>> implements the standardized datagramsReadableType option >>>>>>> >>>>>>> *Web developers*: Positive ( >>>>>>> https://github.com/web-platform-tests/interop/issues/1121) The >>>>>>> Interop 2026 WebTransport proposal received 28 👍 reactions. Developers >>>>>>> also reported active WebTransport use and significant cross-engine >>>>>>> differences. >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> *Ergonomics* >>>>>>> Low. The default stream better matches Datagram message semantics. >>>>>>> Applications needing BYOB allocation control must explicitly opt into >>>>>>> "bytes" , making the semantic tradeoff visible in application code. >>>>>>> >>>>>>> *Activation* >>>>>>> The main activation risk is existing Chromium-specific code assuming >>>>>>> that transport.datagrams.readable always supports BYOB readers. Such >>>>>>> applications must explicitly request datagramsReadableType: "bytes" . >>>>>>> The >>>>>>> feature remains experimentally gated while compatibility and >>>>>>> interoperability are evaluated. >>>>>>> >>>>>>> *Security* >>>>>>> Low. The option changes only the JavaScript stream adapter used to >>>>>>> expose already-received Datagrams. It does not provide additional >>>>>>> network >>>>>>> access, expose new information, or alter WebTransport’s secure-context >>>>>>> and >>>>>>> connection security requirements. >>>>>>> >>>>>>> *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. The implementation is cross-platform Blink code and requires no >>>>>>> WebView-specific integration. The primary compatibility consideration >>>>>>> is >>>>>>> the same as Chrome: applications using a BYOB reader must explicitly >>>>>>> request datagramsReadableType: "bytes" . >>>>>>> >>>>>>> >>>>>>> *Debuggability* >>>>>>> No feature-specific DevTools UI is required. Applications can >>>>>>> inspect whether datagrams.readable supports BYOB by attempting to >>>>>>> acquire >>>>>>> a BYOB reader. Existing WebTransport logging, NetLog, and DevTools >>>>>>> network >>>>>>> diagnostics remain available for connection and Datagram issues. >>>>>>> >>>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>> Yes >>>>>>> Yes. Implemented in cross-platform Blink code without >>>>>>> platform-specific dependencies. >>>>>>> >>>>>>> *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/datagrams.https.any.html?label=experimental&label=master&aligned >>>>>>> >>>>>>> *Flag name on about://flags* >>>>>>> chrome://flags/#enable-experimental-web-platform-features >>>>>>> >>>>>>> *Finch feature name* >>>>>>> WebTransportDatagramsReadableType >>>>>>> >>>>>>> *Rollout plan* >>>>>>> Will ship enabled for all users >>>>>>> >>>>>>> *Requires code in //chrome?* >>>>>>> False >>>>>>> >>>>>>> *Tracking bug* >>>>>>> https://issues.chromium.org/issues/547572475 >>>>>>> >>>>>>> *Availability expectation* >>>>>>> WebKit has implemented the option and corresponding default-stream >>>>>>> behavior in its main branch. Firefox implements the default non-byte >>>>>>> stream >>>>>>> behavior, although explicit "bytes" /BYOB mode does not yet pass >>>>>>> current >>>>>>> public WPT runs. Broad availability is expected as implementations >>>>>>> converge >>>>>>> on the WebTransport specification. >>>>>>> >>>>>>> *Adoption expectation* >>>>>>> Adoption is expected mainly among WebTransport applications that use >>>>>>> BYOB readers or need reliable preservation of Datagram message >>>>>>> boundaries. >>>>>>> Most applications using ordinary readers require no code changes. >>>>>>> >>>>>>> *Adoption plan* >>>>>>> Adoption is expected through WebTransport documentation and Interop >>>>>>> 2026 visibility. Existing Chromium applications using BYOB readers will >>>>>>> need to explicitly set datagramsReadableType: "bytes" when the >>>>>>> feature is >>>>>>> enabled. >>>>>>> >>>>>>> *Estimated milestones* >>>>>>> Shipping on desktop 159 >>>>>>> DevTrial on desktop 155 >>>>>>> Shipping on Android 159 >>>>>>> DevTrial on Android 155 >>>>>>> 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 currently anticipated. The option and default-stream behavior >>>>>>> are already defined in the WebTransport specification. >>>>>>> >>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>> >>>>>>> https://chromestatus.com/feature/5148774971342848?gate=5517621058469888 >>>>>>> >>>>>>> *Links to previous Intent discussions* >>>>>>> Intent to Prototype: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aa86417.edf999b6.71d4e.0a07.GAE%40google.com >>>>>>> >>>>>>> >>>>>>> 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/2684f886-eeec-4900-b634-8cf8d497ca1an%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2684f886-eeec-4900-b634-8cf8d497ca1an%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/CAOMQ%2Bw_HHFqMLJKZfK%2BnUqOpz0bA4MUDm4TQ9o7e3oaYh-vsgw%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_HHFqMLJKZfK%2BnUqOpz0bA4MUDm4TQ9o7e3oaYh-vsgw%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/57b31973-ffed-4af0-a7c1-404f57603a7en%40chromium.org.
