LGTM1; thanks for implementing this! On Thursday, October 1, 2026 at 3:11:20 PM UTC+2 Chromestatus wrote:
> *Contact emails* > [email protected] > > *Specification* > https://xhr.spec.whatwg.org/#interface-progressevent > > *Summary* > ProgressEvent is available in service workers, allowing developers to > construct progress events with lengthComputable, loaded, and total > attributes. This aligns service workers with other worker contexts and the > XMLHttpRequest Standard. > > *Blink component* > Blink > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> > > *Web Feature ID* > xhr <https://webstatus.dev/features/xhr> > > *Motivation* > Blink exposes ProgressEvent in Window, DedicatedWorker, and SharedWorker > contexts, but not in service workers. Exposing it in service workers closes > this gap with the XMLHttpRequest Standard and allows code that constructs > progress events to be reused across worker contexts. The change reuses the > existing implementation without exposing XMLHttpRequest or adding automatic > fetch progress events. Draft implementation: > https://chromium-review.googlesource.com/c/chromium/src/+/8425503 > > *Initial public proposal* > *No information provided* > > *TAG review* > Not applicable. This change implements an existing standardized exposure > requirement already supported by Gecko and WebKit, as documented below. No > new API design is introduced. > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > This change aligns service worker exposure of ProgressEvent with the > XMLHttpRequest Standard and reuses the existing implementation. > Compatibility risk is expected to be low. Adding the global may change > feature-detection results or interact with application-defined > ProgressEvent polyfills in service workers. > > *Gecko*: Shipped/Shipping ( > https://hg.mozilla.org/releases/mozilla-release/raw-file/FIREFOX_140_0_RELEASE/dom/webidl/ProgressEvent.webidl) > Verified > in Firefox 140 release sources: ProgressEvent is exposed to Window and > Worker, and ServiceWorkerGlobalScope includes the Worker global name. This > establishes service worker exposure in a released version; it does not > identify the first supported version. ServiceWorker global definition: > https://hg.mozilla.org/releases/mozilla-release/raw-file/FIREFOX_140_0_RELEASE/dom/webidl/ServiceWorkerGlobalScope.webidl > > *WebKit*: Shipped/Shipping ( > https://github.com/apple-oss-distributions/WebKit/blob/WebKit-7614.1.25.0.30/Source/WebCore/dom/ProgressEvent.idl) > Verified > in Apple's published WebKit-7614.1.25.0.30 source distribution: > ProgressEvent is exposed to Window and Worker, and ServiceWorkerGlobalScope > includes the Worker global name. This is release-source evidence, not a > claim about the first supported Safari version. ServiceWorker global > definition: > https://github.com/apple-oss-distributions/WebKit/blob/WebKit-7614.1.25.0.30/Source/WebCore/workers/service/ServiceWorkerGlobalScope.idl > > *Web developers*: No signals > > *Other signals*: > > *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 risk is expected. This change adds the existing ProgressEvent > interface to service workers without removing existing APIs or changing its > behavior in other contexts. Code that detects or defines a ProgressEvent > global in service workers may behave differently. The change is guarded by > the ProgressEventInServiceWorker base::Feature, which provides a kill > switch. > > > *Debuggability* > Manually verified on macOS using the patched Content Shell and its > DevTools frontend attached to a service worker. Confirmed the > ServiceWorkerGlobalScope context, successful ProgressEvent construction, > expandable object inspection, and the expected lengthComputable, loaded, > total, and isTrusted values. Autocomplete works for ProgressEvent and its > attributes. No DevTools crash or disconnect occurred during these checks. > No dedicated DevTools UI changes are needed for this exposure change. > Chrome DevTools for agents was not separately tested. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > The change uses platform-independent Blink bindings and the existing > ProgressEvent implementation, with no platform-specific restrictions. > Support is intended for Windows, macOS, Linux, ChromeOS, Android, and > Android WebView in service worker contexts > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > The exposure change is covered by extending the existing > xhr/progressevent-constructor.any.js WPT to ServiceWorker, alongside > Window, DedicatedWorker, and SharedWorker. The tests cover construction, > default values, EventInit options, inherited Event attributes, numeric > values, and value conversion. Local runs passed. Blink's default and > virtual/stable service worker interface-listing tests additionally cover > the exposed interface surface. The expanded WPT is included in the CL: > https://chromium-review.googlesource.com/c/chromium/src/+/8425503 > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > ProgressEventInServiceWorker > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/332663431 > > *Measurement* > No dedicated UseCounter is added by this change. Service-worker-specific > adoption is not currently measured. > > *Availability expectation* > Expected to be available in service workers on Blink platforms that > support service workers. > > *Adoption expectation* > Expected to benefit applications and libraries that construct progress > events in service workers or share such code across worker contexts. No > quantitative adoption estimate is available. > > *Adoption plan* > Communicate the change through the Blink intent process, upstream the > expanded Web Platform Tests, and update browser compatibility documentation > to reflect service worker 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? > None. This change reuses Blink's existing ProgressEvent implementation and > introduces no additional dependencies. > > *Estimated milestones* > Shipping on desktop 157 > Shipping on Android 157 > Shipping on WebView 157 > > *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 anticipated for this change. The XMLHttpRequest Standard already > exposes ProgressEvent to Window and Worker. This change implements the > existing exposure requirement in service workers. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5069584943153152?gate=6152298232414208 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ab51ccd.c518491a.183cfe.046f.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/7853862f-2d7c-46fb-890d-1d2bb7d5b462n%40chromium.org.
