This intent has ended up in a strange state in the chromestatus tool,
missing various flags I would have expected. Is that because the intent
predates some of the chromestatus updates or because it started as an
origin trial? If so, maybe the simplest is to refile it, or can it be
made to be a proper Intent to Ship with all the buttons and bullets?
Another few things though, and I hope I'm not repeating something
already covered elsewhere.
First, I really like the idea of doing optimizations that have a
measurable impact on user behaviour and probably also power usage and
energy usage so I approve of this work. But then I have questions.
The text mentions that WebKit uses an alignment on 30 milliseconds
intervals, but what is the intention for Chromium? Also 30 milliseconds?
If the idea is for it to be 30 milliseconds, that would be too sparse to
allow 60 fps animations run on setTimeout. If so, is that intentional,
and would that be acceptable?
I ask in particular, because "uninteresting iframe" is vaguely defined
so I don't know how much content will be misclassified as "uninteresting".
In general, is the answer to my questions above covered by some
specification we can point people to when they wonder why something
behaves inexplicably?
/Daniel
On 2024-03-13 03:00, Domenic Denicola wrote:
Can you fill out the interoperability and compatibility risks section
here? I don't think standards position requests are necessary, but
saying how this behavior might break existing sites that assume
Chromium's current behavior, and how this new behavior compares to
WebKit and Gecko, would be helpful.
Also, can you request the
privacy/security/enterprise/debuggability/testing gates on Chrome Status?
On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen <zheda.c...@intel.com> wrote:
Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.
https://chromestatus.com/feature/5106220399853568
On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:
*Intent to Ship: Add JavaScript timer wake up alignment for
unimportant cross-origin frames*
Contact emails
zheda...@intel.com, fdo...@chromium.org
Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
Summary
Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant frames
are eligible to use JS timer alignment. WebKit uses the policy
to align DOM timer of non-interacted cross origin frames to
30ms. This feature adds JavaScript timer wake up alignment for
unimportant frames on foreground pages. Unimportant frames
means they are cross origin, visible but have non-large
proportion of page’s visible area, and have no user
interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092
Blink component
Blink>PerformanceAPIs>Timers
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers>
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
None
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/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)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Flag name on chrome://flags
None
Finch feature name
ThrottleUnimportantFrameTimers
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/40942028
Estimated milestones
Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
DevTrial on Android
121
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/5106220399853568
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
On Thursday, March 7, 2024 at 12:15:41 PM UTC+8
dom...@chromium.org wrote:
Switching to an Intent to Ship sounds good. Can you update
the process stage in the ChromeStatus tool, fill out any
necessary fields that differ between the stages, and
either start a new thread, or paste the newly-generated
Intent here?
On Thu, Mar 7, 2024 at 2:48 AM Etienne Pierre-doray
<etie...@google.com> wrote:
I'm working with Zheda and Francois to get this
feature out, chiming in
In general, I think it's best to file a formal
Intent to Ship if you want to go to 50% stable.
I agree, I'd consider this feature ready to ship, we
have enough confidence from previous stable
experiments to roll it out.
The main reason for doing a 50/50 experiment first is
to more accurately measure impact on CWV.
There aren't clear guidelines from finch otherwise on
the exact % when ramping up from 1% to 100%, or when
intermediate steps are needed at all; our team has
been following a 1/50/100 pattern (we received
feedback for other features that fewer intermediate
steps was desirable for web devs).
For blink purpose, I'd suggest we switch this to an
'Intent to ship'.
On Mon, Mar 4, 2024 at 5:06 PM Domenic Denicola
<dom...@chromium.org> wrote:
In general, I think it's best to file a formal
Intent to Ship if you want to go to 50% stable. To
me it sounds like that might be reasonable here?
I.e. you're fairly confident that the feature is a
good idea to ship, but you want to do a more
cautious rollout. I think many Intent to Ships go
through this sort of cautious rollout; they just
don't necessarily discuss the details of it on
blink-dev.
2024年3月5日(火) 5:19 Mike Taylor
<mike...@chromium.org>:
My concern is going from 1% to 50% on stable -
if something does go wrong, that's a _lot_ of
folks who will experience it. Are you open to
something smaller like 5%? If not, why not?
thx
On 2/29/24 12:34 AM, Zheda Chen wrote:
The volume of data on Beta is too low to draw
any conclusion. Although the experiment on 1%
stable shows some promising result, the data
are not enough and we'd like to gather more
data via experiment on higher percentage of
stable.
After that, based on large volume of data, we
can draw the conclusion and decide next step
(whether to ship the feature).
I contribute the idea and CL source code of
this feature, Francois (fdoray@) is the main
reviewer and the trial is planned by him. Let
us know if you have any concerns and we can
discuss with fdoray@ together.
"Unimportant" frames means they are
cross-origin, visible but use non-large
proportion (<75%) of page's visible area and
have not received a user gesture. All 3
conditions should be met.
On Thursday, February 29, 2024 at 10:26:22 AM
UTC+8 mike...@chromium.org wrote:
Could you say more why you would like to
experiment on 50% of stable, vs
requesting permission to ship? That's
quite a leap from 1% - and it seems you
already have results demonstrating
performance improvements.
Also, mind answering the question of
specifying "unimportant frames"?
On 2/27/24 5:54 AM, Zheda Chen wrote:
fdoray@ launched this trial since Nov
2023, at first canary/dev, and then
beta, 1% stable. The experiments show
statistically improvements to CPU time
on navigation, page load time and input
delay.
So we are requesting to experiment on
50% stable as next step.
Actually the feature should be in origin
trial stage now. But I don't have the
permission to add origin trial stage. I
have to use dev trial instead. Need some
help from webstatus-request@ to grant me
the permission.
On Tuesday, February 27, 2024 at
8:53:34 AM UTC+8 mike...@chromium.org wrote:
Hello,
To clarify: is this intended to be
an I2E, or a Developer Trial?
According to
https://chromestatus.com/feature/5106220399853568,
it appears you are in the dev trial
stage. But you mention stable
experiment below... so perhaps
that's a process mistake?
Can you give more info on the
experiment timelines and what stable
percentages you are requesting
permission to experiment on?
On 2/22/24 2:30 AM, Zheda Chen wrote:
Contact emails
zheda...@intel.com, fdo...@chromium.org
Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
Summary
Align wake ups of JavaScript timers
for unimportant cross-origin
frames. Currently, DOM timers <32ms
are all opt-out from AlignWakeUps
[1] due to performance concerns.
This is very conservative and
actually some unimportant frames
are eligible to use JS timer
alignment. WebKit uses the policy
to align DOM timer of
non-interacted cross origin frames
to 30ms. This feature adds
JavaScript timer wake up alignment
for unimportant frames on
foreground pages. Unimportant
frames means they are cross origin,
visible but have small proportion
of page’s visible area, and have no
user interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092
Do you have plans to specify this
concept of "unimportant frames"
somewhere?
Blink component
Blink>PerformanceAPIs>Timers
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers>
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
None
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/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
Goals for experimentationWe plan to
experiment on stable to confirm
whether we observe same performance
improvement as on lower channels
and similar power benefit as in the
lab. We will decide whether this
feature ships based on the
experiment data.
Ongoing technical constraints
None
Debuggability
None
Will this feature be supported on
all six Blink platforms (Windows,
Mac, Linux, ChromeOS, Android, and
Android WebView)?
Yes
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Flag name on chrome://flags
None
Finch feature name
ThrottleUnimportantFrameTimers
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/40942028
Estimated milestones
DevTrial on desktop
122
DevTrial on Android
122
Link to entry on the Chrome
Platform Status
https://chromestatus.com/feature/5106220399853568
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+...@chromium.org.
To view this discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1996ccec-101e-4738-99d9-56855c8d33ec%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1996ccec-101e-4738-99d9-56855c8d33ec%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 on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-MsdhXA1Edddo_g0MXevycPrroqyxNXVm9S-4aCwZXTw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-MsdhXA1Edddo_g0MXevycPrroqyxNXVm9S-4aCwZXTw%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 on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84ea7a78-d9e2-40d2-adf7-3185f4d2a2d9%40gmail.com.
