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/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-constructor.html?label=experimental&label=master&aligned>
https://wpt.fyi/results/xhr/progressevent-interface.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.
