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>.
