LGTM2 On Wed, Mar 5, 2025 at 9:36 AM Daniel Bratell <brat...@sarasas.se> wrote:
> LGTM1 > > (I'm a bit worried that it won't be interoperable between browsers but > since it's so easy to implement, and since other browsers have said they > are on top of it, I think it will be fine) > > /Daniel > On 2025-02-27 06:18, Domenic Denicola wrote: > > > > On Thu, Feb 27, 2025 at 1:41 AM 'Dan Clark' via blink-dev < > blink-dev@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 <https://bugs.webkit.org/show_bug.cgi?id=288688>, thanks for the > push! > > >> >> -- 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c2e23875-cc0b-4cc6-88d8-9bc22da8f9b1n%40chromium.org?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/CAM0wra-jb7gosA4xBp28QpTQ%2Bw9mEm%2Brt7OX8LASPD7GTvt%2BaA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-jb7gosA4xBp28QpTQ%2Bw9mEm%2Brt7OX8LASPD7GTvt%2BaA%40mail.gmail.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/23beebb0-05ef-4b10-b81d-b33b1c127284%40sarasas.se > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/23beebb0-05ef-4b10-b81d-b33b1c127284%40sarasas.se?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/CADsXd2PPPj2okZk2YiMsSgK9oJPwEknfUFLE8rVMHN-uu9rEiw%40mail.gmail.com.
