Can you please request reviews for privacy, security, enterprise, debuggability and testing?
On Monday, February 17, 2025 at 6:07:07 PM UTC+1 Mingyu Lei wrote: > 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/d68779d2-8d63-4d48-a262-dd27e6c5485an%40chromium.org.
