LGTM2

On Thursday, November 5, 2026 at 11:50:20 AM UTC-8 [email protected] 
wrote:

> LGTM1
>
>  
>
> *From:* [email protected] <[email protected]> *On Behalf Of *
> Chromestatus
> *Sent:* Thursday, November 5, 2026 9:37 AM
> *To:* [email protected]
> *Cc:* Daniel Clark <[email protected]>; [email protected]; 
> [email protected]; Viktoriya Bryhider <[email protected]>
> *Subject:* [blink-dev] Intent to Ship: WebTransport connection statistics
>
>  
>
> *Contact emails*
>
> [email protected]
>
> *Explainer*
>
> https://github.com/w3c/webtransport/blob/main/explainer.md#stats
>
> *Specification*
>
> https://w3c.github.io/webtransport/#dictdef-webtransportconnectionstats 
>
> *Design docs*
>
>
> https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/getStats
> https://w3c.github.io/webtransport/#web-transport-connection-stats
>
> *Summary*
>
> WebTransport.getStats() provides asynchronous statistics for an existing 
> connection: round-trip time measurements when available, an estimated 
> sending rate when available, and counts of expired, lost, and dropped 
> datagrams. Statistics remain accessible after the connection closes. 
> Chromium does not currently expose connection byte or packet totals. 
>
> *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 applications need to distinguish connection latency, 
> congestion, and datagram loss or expiration from application-side delays. A 
> single asynchronous call exposes a snapshot of the existing connection's 
> health to help developers adapt sending behavior and troubleshoot problems. 
> It does not create a connection or change how application data is 
> transmitted. 
>
> *Initial public proposal*
>
> *No information provided*
>
> *TAG review*
>
>
> https://github.com/w3ctag/design-reviews/issues/1212#issuecomment-5071009850 
>
> *TAG review status*
>
> Issues addressed
>
> *Goals for experimentation*
>
> None 
>
> *Risks*
>
>  
>
> *Interoperability and Compatibility*
>
> This is an additive method on an existing WebTransport object: existing 
> code is unaffected if it does not use the new method. Developers must check 
> for method support and handle a rejection or missing dictionary members 
> when working across browsers. Firefox and Safari expose getStats(), but 
> implementation maturity and returned fields vary between all browsers. The 
> WebTransport specification currently defines connection byte/packet 
> counters (bytesSent, bytesSentOverhead, bytesAcknowledged, packetsSent, 
> bytesLost, packetsLost, bytesReceived, packetsReceived) and atSendCapacity; 
> Chromium does not expose these members. Applications should check for 
> optional members rather than assume that every browser returns the same 
> subset. 
>
> *Gecko*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/158#apis) 
> WebTransport.getStats() 
> shipped in Firefox 158, released October 13, 2026.
>
> *WebKit*: Shipped/Shipping (
> https://github.com/WebKit/WebKit/blob/WebKit-7625.2.8/Source/WebKit/NetworkProcess/webtransport/cocoa/NetworkTransportSessionCocoa.mm#L410-L413)
>  Safari 
> 27.2 exposes  WebTransport.getStats(), but its WebKit(7625.2.8) 
> implementation returns default-initialized connection statistics. WebKit 
> main has since added bytesSent and bytesReceived counters.
>
> *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*
>
> Values are asynchronous snapshots, not continuously updated measurements. 
> RTT fields are in milliseconds; estimatedSendRate is in bits per second and 
> can be null when no estimate is available.
>
> *Activation*
>
> There is no distinct activation risk identified for 
> WebTransport.getStats(). Enabling it exposes an additive method; sites that 
> do not call it keep their existing WebTransport behavior.
>
> *Security*
>
> The method returns aggregate connection information for a WebTransport 
> object the caller already owns; it does not disclose payloads or peer 
> credentials and does not add a new connection capability. RTT and estimated 
> send rate can reveal characteristics of a user's network and help 
> fingerprint or correlate activity. The WebTransport spec limits disclosure 
> of connection and datagram counters on connections subject to pooling while 
> permitting selected pooled-connection measurements such as RTT and 
> estimated send rate.
>
> *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 API and does not 
> change connection establishment or network behavior. 
>
>  
>
> *Debuggability*
>
> Applications can inspect getStats() results from script or the DevTools 
> Console. No dedicated DevTools connection-statistics UI is required for the 
> API to work. 
>
> *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/stats.https.any.html
>
> *Flag name on about://flags*
>
> enable-experimental-web-platform-features 
>
> *Finch feature name*
>
> WebTransportStats 
>
> *Rollout plan*
>
> Will ship enabled for all users
>
> *Requires code in //chrome?*
>
> False
>
> *Tracking bug*
>
> https://issues.chromium.org/issues/573538454
>
> *Availability expectation*
>
> Firefox 158 and Safari 26.4 expose WebTransport.getStats(), although 
> implementation maturity and available dictionary fields differ. 
>
> *Adoption expectation*
>
> Adoption is expected primarily among WebTransport applications that 
> monitor network performance or datagram delivery.
>
> *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
>
> 124
>
> Shipping on Android
>
> 159
>
> DevTrial on Android
>
> 124
>
> 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.
>
> *Link to entry on the Chrome Platform Status*
>
> https://chromestatus.com/feature/5120203192139776?gate=5581427851788288
>
> 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/6aecbed8.dafb4d6f.4865.0071.GAE%40google.com
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aecbed8.dafb4d6f.4865.0071.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/6472eeaa-d587-4fb7-b11e-33dceec7fde1n%40chromium.org.

Reply via email to