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 On Wednesday, February 19, 2025 at 8:15:40 PM UTC-8 Mingyu Lei wrote: > Sorry I misunderstood the process before and I have just requested for > those reviews. > > On Wednesday, February 19, 2025 at 8:40:54 PM UTC+9 Yoav Weiss wrote: > >> 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 <dom...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Feb 15, 2025 at 12:41 AM Stephen Chenney <sche...@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/c2e23875-cc0b-4cc6-88d8-9bc22da8f9b1n%40chromium.org.
