Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Reilly Grant]

+1 to documenting Chromium's behavior in an evergreen format even if this
isn't formally specified. I am constantly getting questions from developers
about this and it is driving FUD about the capability of the web platform.

On Tue, Mar 26, 2024 at 7:47 PM Domenic Denicola 
wrote:

> LGTM3.
>
> With my HTML Standard editor hat on, I agree that this area does not
> benefit from tight specification.
>
> However, in the past we've seen web developers be pretty confused by what
> each browser's behavior is, for this and other inactive-tab /
> offscreen-iframe / etc. throttling behaviors. Would it be possible to have
> some sort of document summarizing Chromium's timer throttling behavior?
> Probably the easiest would be in the source tree, but an evergreen article
> on developer.chrome.com or MDN would also be great. (This feedback is
> optional and does not block shipping.)
>
> On Wednesday, March 27, 2024 at 4:02:00 AM UTC+9 Mike Taylor wrote:
>
>> LGTM2
>> On 3/26/24 1:27 PM, Yoav Weiss (@Shopify) wrote:
>>
>> LGTM1
>>
>> On Monday, March 25, 2024 at 4:42:55 PM UTC+1 Mike Taylor wrote:
>>
>>> 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
>>> 
>>> ]
>>>
>>>
 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
>>> )
>>> 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 
>>> wrote:
>>>
 On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:


 On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen 
 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".
>

 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Domenic Denicola]

LGTM3.

With my HTML Standard editor hat on, I agree that this area does not 
benefit from tight specification.

However, in the past we've seen web developers be pretty confused by what 
each browser's behavior is, for this and other inactive-tab / 
offscreen-iframe / etc. throttling behaviors. Would it be possible to have 
some sort of document summarizing Chromium's timer throttling behavior? 
Probably the easiest would be in the source tree, but an evergreen article 
on developer.chrome.com or MDN would also be great. (This feedback is 
optional and does not block shipping.)

On Wednesday, March 27, 2024 at 4:02:00 AM UTC+9 Mike Taylor wrote:

> LGTM2
> On 3/26/24 1:27 PM, Yoav Weiss (@Shopify) wrote:
>
> LGTM1
>
> On Monday, March 25, 2024 at 4:42:55 PM UTC+1 Mike Taylor wrote:
>
>> 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 
>> 
>> ]
>>   
>>
>>> 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 
>> )
>>  
>> 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  
>> wrote:
>>
>>> On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:
>>>
>>>
>>> On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  
>>> 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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

LGTM2

On 3/26/24 1:27 PM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Monday, March 25, 2024 at 4:42:55 PM UTC+1 Mike Taylor wrote:

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

]

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

)
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
 wrote:

On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:



On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen
 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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Yoav Weiss (@Shopify)]

LGTM1

On Monday, March 25, 2024 at 4:42:55 PM UTC+1 Mike Taylor wrote:

> 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 
> 
> ]
>   
>
>> 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 
> ) 
> 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  
> wrote:
>
>> On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:
>>
>>
>> On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

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 
]


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 
) 
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  
wrote:


On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:



On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen
 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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

['Etienne Pierre-doray' via blink-dev]

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

]


> 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
)
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  wrote:

> On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:
>
>
> On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:



On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  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



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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Yoav Weiss (@Shopify)]

On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  wrote:

> The privacy/security/enterprise/debuggability gates are requested on
> Chrome Status. Testing gate to be requested later.
>
> "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.
>
> 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.


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

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

The privacy/security/enterprise/debuggability gates are requested on Chrome 
Status. Testing gate to be requested later.

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

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

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

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



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 
?

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 
.



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,
   

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

*Intent to Ship: Add JavaScript timer wake up alignment for unimportant 
cross-origin frames*

Contact emails
zheda.c...@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 


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 

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


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 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

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 
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/70b96db6-f908-48dc-82b8-a68eab3cce60%40chromium.org.

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

Yes the intent started as an origin trial, now more details and bullets are 
added in ChromeStatus and I'm about to send "intent to ship".

As for your question about "alignment interval", the alignment interval for 
Chromium would be 32ms. The specification 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

Actually, different browser vendors do have different implementation about 
the wait length of time. Webkit would align DOM timer of non-interacted 
cross origin frames to 30ms, while in Gecko, all DOM timers of frames (both 
same origin and cross origin) are aligned to 16ms. So web developers cannot 
expect the delay is the same across user agents. I already put this note to 
"interoperability and compatibility risks" of the feature in ChromeStatus.

If the work is related to animation, then requestAnimationFrame is much 
better at scheduling animation work than JavaScript timers. It synchronizes 
with the refresh rate of the device, ensuring you only get one callback per 
displayable frame, and you get the maximum amount of time to construct that 
frame. requestAnimationFrame would not be affected.
https://developer.chrome.com/blog/timer-throttling-in-chrome-88#animation

On Thursday, March 14, 2024 at 12:32:52 AM UTC+8 Daniel Bratell wrote:

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

-- 
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/d8c084b4-e00f-4784-93b8-d0fbb153d978n%40chromium.org.

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

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  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/b1ed1e28-bc0b-4be4-b328-de4a872806ecn%40chromium.org.

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Daniel Bratell]

One more question, is requestAnimationFrame affected at all or will that 
still work just as before?


/Daniel

On 2024-03-13 17:32, Daniel Bratell wrote:


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



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

?
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) 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Daniel Bratell]

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



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

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

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Domenic Denicola]

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

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

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

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

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

*Intent to Ship: Add JavaScript timer wake up alignment for unimportant 
cross-origin frames*

Contact emails
zheda.c...@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 


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 

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

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