LGTM2 On Thursday, October 15, 2026 at 5:47:21 PM UTC-7 Mike Taylor wrote:
> LGTM1 > On 10/15/26 5:49 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *Explainer* > > https://github.com/w3c/webtransport/blob/main/explainer.md#11-handling-session-draining > > *Specification* > https://w3c.github.io/webtransport/#dom-webtransport-draining > > *Design docs* > > > https://github.com/w3c/webtransport/blob/main/explainer.md#11-handling-session-draining > > *Summary* > WebTransport.draining is a promise that resolves when the server indicates > that the WebTransport session will be gracefully retired. Applications can > use this signal to establish a replacement session while existing streams > and the current session remain usable. > > *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* > A WebTransport server may need to retire a session for maintenance, load > balancing, deployment, or connection-lifetime management. Without a > draining signal, an application learns about this only when the session > closes, which can cause an avoidable interruption while a replacement > connection is established. The draining promise gives the application > advance notice without changing the lifetime or usability of the current > session. > > *Initial public proposal* > *No information provided* > > *TAG review* > This is a small incremental addition to an existing feature which is > already standardized. > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > Compatibility risk is low because this adds a new read-only promise > attribute to WebTransport and does not change existing behavior. Code that > does not read the attribute is unaffected. The promise resolves only after > a server-side draining signal and does not close the session or alter > existing stream semantics. Interoperability risk is low. The attribute is > available in Firefox 155 and Safari 26.4. Applications supporting older > browsers should check for the attribute before using it. > > *Gecko*: Shipped/Shipping ( > https://bugzilla.mozilla.org/show_bug.cgi?id=2007160) WebTransport.draining > shipped > in Firefox 155 - > https://chromium.googlesource.com/external/github.com/mdn/browser-compat-data/%2B/HEAD/api/WebTransport.json#804 > > *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=302762) > WebTransport.draining > is available in Safari 26.4 - > https://chromium.googlesource.com/external/github.com/mdn/browser-compat-data/%2B/HEAD/api/WebTransport.json#811 > > *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* > The API is a stable Promise<undefined> attribute, consistent with the > existing WebTransport.ready and WebTransport.closed lifecycle promises. It > can be observed before or after the connection becomes ready. The promise > resolves at most once. > > *Activation* > No special activation is required. A WebTransport server triggers the > promise by sending the protocol-defined draining signal. Sites that do not > use the new attribute are unaffected. > > *Security* > This does not grant a new capability or expose application data. It > exposes a server-originated lifecycle signal for an already established, > secure-context WebTransport session. The information is controlled by the > connected server and is closely related to connection state already > observable by the application. > > *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 read-only attribute and does not modify existing > WebTransport behavior. > > > *Debuggability* > The promise and its state can be inspected from JavaScript. Existing > DevTools Network tooling continues to expose the WebTransport connection > and its streams. No new DevTools UI is required for the initial launch. > > *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/draining.https.any.html?label=experimental&label=master&aligned > > *Flag name on about://flags* > enable-experimental-web-platform-features > > *Finch feature name* > WebTransportDraining > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/564353368 > > *Availability expectation* > WebTransport is available across the major browser engines, and draining > is part of the W3C WebTransport API. The feature is expected to remain > available across browsers as implementations converge on the current > specification. > > *Adoption expectation* > Adoption is expected among applications that maintain long-lived > WebTransport sessions and need to replace sessions gracefully during server > maintenance, deployment, load balancing, or connection-lifetime management. > Broader adoption will follow overall WebTransport usage. > > *Adoption plan* > No dedicated outreach campaign is planned. Adoption is expected to occur > organically through WebTransport documentation and client and server > library support. > > *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 158 > DevTrial on desktop 153 > Shipping on Android 158 > DevTrial on Android 153 > Shipping on WebView 158 > > *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 draining promise semantics. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/6427766428925952?gate=4865096399585280 > > 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/6ad14a65.d597a17e.2fbf8.0100.GAE%40google.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad14a65.d597a17e.2fbf8.0100.GAE%40google.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/84523bfc-ecc7-4945-beb9-4559e83b8b2bn%40chromium.org.
