Thank you for the answers Etienne. Once the Testing bit has been
requested, I'm happy to give an LGTM.
On 3/25/24 11:08 AM, Etienne Pierre-doray wrote:
Right - that's my question. I also asked how similar this change
is to whatever Safari implements - do they also align wakeups of
JS timers for cross-origin, < 75% of viewport, frames that haven't
yet received a user gesture? You previously wrote "non-interacted
cross origin frames" for WebKit. Is there also a viewport condition?
I don't think WebKit has a viewport condition. [code
<https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/Document.cpp#L4005>]
I believe the question Mike asked is not if this is spec
compliant, but if the specifics of this should be more tightly
specified, given that both WebKit and Chromium find a similar
intervention useful.
Defining this concept in the spec would presumably be used to more
strictly define when throttling is allowed (1) or mandatory (2) by
browsers. I really don't think it's useful to specify this more
tightly in the spec, as it makes performance interventions overly
restrictive and is prone to rotting over time, as common patterns and
APIs evolve.
1- Allowing throttling *only* for some definition of unimportant
frames could provide a more predictable platform to web devs, but it
seems overly restrictive on what the platform is allowed to do, and
locks us in wrt. the kind of performance intervention we're allowed to
do. This is already not true: both Webkit and blink implement various
throttling in power-reducing situations other than unimportant frames.
2- It's unclear how making throttling mandatory in certain situations
brings value to web devs, especially if the intervention is different
among browsers. It does however add unnecessary constraints on the
platform.
As a case in point, the spec specifies a mandatory 4ms delay on
settimeout (8.6.5
<https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers>)
with a nesting level greater than 5. This intervention doesn't really
make sense in modern day browsers, and neither blink or webkit are
spec compliant (in distinct ways).
On Fri, Mar 22, 2024 at 2:57 PM Mike Taylor <miketa...@chromium.org>
wrote:
On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:
On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen
<zheda.c...@intel.com> wrote:
The privacy/security/enterprise/debuggability gates are
requested on Chrome Status. Testing gate to be requested later.
Thanks - we've been asked to not send LGTMs until all bits have
been requested. Can you let us know when Testing is?
"Unimportant" cross origin 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. The criteria are too long so we
use "unimportant" concept here.
Thank you - that's much more clear to me now.
This intervention is spec-compliant. The spec mentions "the
SetTimeout/SetInterval API does not guarantee that timers
will run exactly on schedule. Delays due to CPU load, other
tasks, etc, are to be expected". The wait length of time is
implementation-defined, "which is intended to allow user
agents to pad timeouts as needed to optimize the power usage
of the device". In Safari, DOM timers of non-interacted cross
origin frames are aligned to 30ms after reaching max nesting
level (>=5). In Firefox, all DOM timers of frames (both same
origin and cross origin) are aligned to 16ms. See details
in"Interoperability and Compatibility Risks", "Safari views",
"Firefox views".
I believe the question Mike asked is not if this is spec
compliant, but if the specifics of this should be more tightly
specified, given that both WebKit and Chromium find a similar
intervention useful.
Right - that's my question. I also asked how similar this change
is to whatever Safari implements - do they also align wakeups of
JS timers for cross-origin, < 75% of viewport, frames that haven't
yet received a user gesture? You previously wrote "non-interacted
cross origin frames" for WebKit. Is there also a viewport condition?
On Thursday, March 21, 2024 at 1:27:16 AM UTC+8
mike...@chromium.org wrote:
You should be able to see all the various bits for
approvals in your chromestatus entry now, can you fill
them out please?
There have been a few questions/comments about the lack
of clarity of what "unimportant cross-origin frames" are.
What exactly is the definition? You mention that Safari
has a similar intervention - how similar is it? Do we
know? I wonder if there is alignment for this
"unimportant cross-origin frame" concept, if we shouldn't
specify that somehow.
On 3/15/24 2:58 AM, 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. The alignment interval is 32ms. [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
"Other vendors already have interoperable
implementation" Safari has a similar intervention. DOM
timers of non-interacted cross origin frames are aligned
to 30ms. In Firefox, all DOM timers (both same-origin
and cross-origin) in foreground pages would be aligned
to 16ms. "A mature specification in the relevant
standards body" This intervention is spec-compliant. The
spec mentions "the SetTimeout/SetInterval API does not
guarantee that timers will run exactly on schedule.
Delays due to CPU load, other tasks, etc, are to be
expected. ". The wait length of time is
implementation-defined, "which is intended to allow user
agents to pad timeouts as needed to optimize the power
usage of the device. "
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
"A shared test suite for that specification" It isn't
clear what should be tested specifically for this
intervention since the spec allows waiting for an
"implementation-defined" length.
/Gecko/: Shipped/Shipping
In Firefox, all DOM timers of frames (both same origin
and cross origin) are aligned to 16ms
/WebKit/: Shipped/Shipping
In Safari, DOM timers of non-interacted cross origin
frames are aligned to 30ms after reaching max nesting
level (>=5)
/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>?
Yes
This intervention doesn't require changes to the spec.
Timers are already covered by Web Platform Tests.
Flag name on chrome://flags
None
Finch feature name
ThrottleUnimportantFrameTimers
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/40942028
Launch 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
Links to previous Intent discussions
This intent message was generated by Chrome Platform
Status <https://chromestatus.com/>.
On Friday, March 15, 2024 at 6:24:06 AM UTC+8
mike...@chromium.org wrote:
The privacy and security teams review all intents,
so requesting reviews and answering the relevant
questionnaires is the best path forward.
Looking forward to the new I2S - thanks!
On 3/14/24 11:22 AM, Zheda Chen wrote:
More details are updated in ChromeStatus, including
interoperability and compatibility risks,
Safari/Firefox views, web platform tests. It
compares the behaviors across different browser
vendors.
https://chromestatus.com/feature/5106220399853568
Will send the updated "intent to ship" to this
thread later if it looks good.
AFAIK, I don't see potential privacy/security
issues, so can i set "security review status" and
"privacy review status" to "not applicable"? Please
let us know if you have any concerns.
On Wednesday, March 13, 2024 at 10:00:35 AM UTC+8
dom...@chromium.org 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...@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
--
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/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%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/97506e50-9dcb-42b2-900e-685d43bfa341%40chromium.org.
