Intent to Ship: Update ProgressEvent to use double type for 'loaded' and 'total'

[Chromestatus]

Contact emails

le...@chromium.org

Explainer

https://github.com/whatwg/xhr/pull/394

Specification

https://whatpr.org/xhr/394.html#interface-progressevent

Summary

The ProgressEvent has attributes `loaded` and `total` indicating the progress, and their type is `unsigned long long` now. With this feature, the type for these two attributes is changed to `double` instead, which gives the developer more control over the value. For example, the developers can now create a ProgressEvent with the `total` of 1 and the `loaded` increasing from 0 to 1 gradually. This is aligned with the default behavior of the <progress> HTML element if the max attribute is omitted.

Blink component

Blink

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

This change will not be visible if the web developers implement the ProgressEvent using non-negative integer in the loaded or total fields. However, if a negative number or a decimal number is used, it would be converted to unsigned integer before, but will be returned without any conversion after this feature is introduced. For example - `new ProgressEvent("event", { loaded: 1.1 }).loaded` is 1 now, but it will be 1.1 after the change. - `new ProgressEvent("event", { loaded: -1 }).loaded` is 18446744073709552000 now, but it will be -1 after the change.

Gecko: Positive (https://github.com/whatwg/xhr/pull/394#issuecomment-2607316190)

WebKit: Positive (https://github.com/whatwg/xhr/pull/394#issuecomment-2603844507)

Web developers: Positive (https://github.com/webmachinelearning/writing-assistance-apis/issues/15)

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?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/xhr/progress-events-response-data-gzip.htm?label=experimental&label=master&aligned https://wpt.fyi/results/xhr/progressevent-constructor.html?label=experimental&label=master&aligned https://wpt.fyi/results/xhr/progressevent-interface.html?label=experimental&label=master&aligned

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

This feature changes the definition of existing implementation of ProgressEvent so it's not possible to conduct a finch experiment.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

135

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5067669587623936?gate=5176277298053120

This intent message was generated by Chrome Platform Status.

[Stephen Chenney]

Fine with no Finch, but a kill switch should be included on a change like this, just in case there is more breakage than anticipated. Even better, if possible, would be UseCounter measurements of how often sites would see different behavior.

Stephen.

 

Non-finch justification

This feature changes the definition of existing implementation of ProgressEvent so it's not possible to conduct a finch experiment.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

135

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5067669587623936?gate=5176277298053120

This intent message was generated by Chrome Platform Status.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67aec131.2b0a0220.80420.0241.GAE%40google.com.

[Domenic Denicola]

How would you propose implementing a kill switch for an IDL feature like this? Since IDL cannot be guarded behind flags, it would be pretty difficult. (Custom bindings, maybe?)

I don't believe this minor feature requires such caution.

[Stephen Chenney]

OK, I should have looked more carefully at the context for the proposed change. Yes, there is no way to kill switch this so I withdraw my concern.

I am still worried in particular about the change from "negative goes to infinity" to "negative stays negative" but I accept there's nothing to be done apart from launching and seeing what, if anything, happens.

Stephen.

[Mingyu Lei]

These two fields are used to indicate the loaded and total progress, it will be very surprised to see some sites passing in a negative number for either of these fields and relying on the negative -> infinity number conversion behavior to make something work.

Code wise, I'm not sure if it's possible to get the "wrong" usage metrics without introducing the new change, since what we now get from the ProgressEvent constructor is the already-converted uint64.

Stephen.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

Can you please request reviews for privacy, security, enterprise, debuggability and testing?

[Mingyu Lei]

Sorry I misunderstood the process before and I have just requested for those reviews. 

[Dan Clark]

The spec PR thread has a Gecko bug linked (https://bugzilla.mozilla.org/show_bug.cgi?id=1943649), but I don't see a WebKit bug. Can you please file one to ensure we don't lost track of WebKit aligning to the proposed change?

-- Dan

Stephen.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

On Thu, Feb 27, 2025 at 1:41 AM 'Dan Clark' via blink-dev <blin...@chromium.org> wrote:

The spec PR thread has a Gecko bug linked (https://bugzilla.mozilla.org/show_bug.cgi?id=1943649), but I don't see a WebKit bug. Can you please file one to ensure we don't lost track of WebKit aligning to the proposed change?

Done, thanks for the push!

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c2e23875-cc0b-4cc6-88d8-9bc22da8f9b1n%40chromium.org.