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. On Monday, February 17, 2025 at 10:32:58 PM UTC+9 Stephen Chenney wrote: > 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. > > On Sun, Feb 16, 2025 at 8:36 PM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Sat, Feb 15, 2025 at 12:41 AM Stephen Chenney <schen...@chromium.org> >> wrote: >> >>> >>> >>> On Thu, Feb 13, 2025 at 11:06 PM Chromestatus < >>> ad...@cr-status.appspotmail.com> wrote: >>> >>>> 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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? 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 >>> >>> >>> 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. >>> >> >> 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. >>> >>> >>>> >>>> >>>> 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 >>>> <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 blink-dev+unsubscr...@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 >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67aec131.2b0a0220.80420.0241.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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5a6937d-9476-4b93-ae4e-641986621401n%40chromium.org.
