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/CAGsbWzTJhi9D%2BGAKbLtb1oyy1qxaHE8veyOscCzo0%2BxmDq8-Yw%40mail.gmail.com.
