If I'm reading the Chromium Dashboard schedule
<https://chromiumdash.appspot.com/schedule> correctly, M97 stable will
be released early January, so after the holiday season. It seems
worthwhile to try and ship this at that point (but not in M96).
On Thu, Oct 14, 2021 at 4:12 AM Wanming Lin <wanming....@intel.com> wrote:
Thank you all for your great support!
There's no more outstanding questions or bugs in my mind that
might block shipping this, but I need to get 3 LGTMs from you to
process the final ship.
Is that possible we could cherry-pick it to M96? Otherwise we have
to wait about 4 months for M98 stable, and M96 stable release at
Nov 16, 2021, we may have some latency for bug reports. But it's
up to your opinions. :)
Thanks,
Wanming
On Wednesday, October 13, 2021 at 9:54:59 PM UTC+8
mike...@chromium.org wrote:
It does seem worth trying to ship this given the lack of
(known) bugs,
but maybe we should consider waiting until M98 to avoid sites
needing to
deploy fixes during the holiday season, assuming a few weeks
of latency
for bug reports.
On 10/13/21 9:18 AM, Philip Jägenstedt wrote:
> Thanks for explaining this, Rakina, I definitely didn't get
the whole
> context on my first pass.
>
> In particular the fact that current behavior matches Firefox
is a
> strong reason to not make any further changes.
>
> Wanming, are you aware of any other outstanding questions or
bugs that
> might crop up if we attempt to ship this?
>
> On Wed, Oct 13, 2021 at 11:14 AM Rakina Zata Amni
<rak...@chromium.org> wrote:
>> I had a quick chat with Philip about whether we want to fix
crbug.com/1209717 <http://crbug.com/1209717> or not, and I
think we don't need to fix that bug for shipping this.
>> In the bug, the code expected a same-document history
navigation (and its scroll restoration) would happen
synchronously, so any scroll changes that happen after the
navigation was initiated won't be overwritten by the history
scroll restore. Because all history navigation in Chrome needs
to go through the browser process, the same-document history
navigation is actually asynchronous, and so the history scroll
restoration is also asynchronous. Looks like this was fast
enough before that the history scroll restoration might happen
before code with clamping of setTimeout, but now that the
clamping is being removed it's not fast enough, so we got that
regression.
>>
>> That bug was derived from crbug.com/1205285
<http://crbug.com/1205285>, which is noted as having been
fixed by Wikipedia since it's showing a similar behavior on
Firefox with Fission. The fix itself is very simple: they just
needed to set history.scrollRestoration to "manual". As the
motivating bug has been fixed with a simple fix, and
asynchronous same-document history navigation has been in
Chrome for a while (and is also what Firefox is doing), I
think we don't need to reland/make the full fix for
crbug.com/1209717 <http://crbug.com/1209717>.
>>
>>
>> On Tue, Oct 12, 2021 at 11:16 PM Philip Jägenstedt
<foo...@chromium.org> wrote:
>>> Hi Wanming,
>>>
>>> If the reason for reverting no longer applies, then trying
to reland the fix sounds like a reasonable next step. If that
is done and it sticks this time, it seems to me we might be
ready for a final Intent to Ship for this. At least I don't
know what more could be done to vet the change before trying
to let it reach stable.
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Tue, Oct 12, 2021 at 10:14 AM Wanming Lin
<wanmi...@intel.com> wrote:
>>>> Hi all,
>>>>
>>>> Thanks Philip's bridge, I've been connected with the
release managers and completed the new round of origin trial
on M95 (we reached an agreement on reverting the change after
the first M95 Beta release itself). During this period, I
didn't receive any relevant bugs.
>>>>
>>>> But unfortunately, after the origin trial, the fix for
the previous block issue #1209717 was reverted due to
regression at issue #1254867, @rakina is considering that
maybe we can do nothing here because per crbug.com/1205285#c16
<http://crbug.com/1205285#c16>, the original bug on Wikipedia
has been fixed on Wikipedia's side.
Do I understand correctly and the only relationship between this
change and the scroll restoration issue is that the bug is revealed
when a 0 timeout is present?
>>>>
>>>> So we are looking forward your feedbacks, on both the bug
of #1209717 and what's the next step to move forward this
intent-to-ship. Many thanks in advance!
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Wanming
>>>>
>>>> On Tuesday, August 31, 2021 at 8:32:59 PM UTC+8 Philip
Jägenstedt wrote:
>>>>> Hi Wanming, I'll put you in touch with our release
managers so that they're aware of this happening.
>>>>>
>>>>> On Fri, Aug 27, 2021 at 5:38 PM Chris Harrelson
<chri...@chromium.org> wrote:
>>>>>> Sounds good to me.
>>>>>>
>>>>>> On Thu, Aug 26, 2021 at 7:07 PM Wanming Lin
<wanmi...@intel.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The CL has been relanded and following's the new
original plan:
>>>>>>>
>>>>>>> Land the change to M95 - Done
>>>>>>> Allow the change to reach M95 beta (promoted Sep 23)
>>>>>>> Revert it on the M95 branch well before the stable
cut/release (Cut Oct 12)
>>>>>>> Get back to this thread with test reports on M95 beta
>>>>>>>
>>>>>>> Does that sound good to you? Looks like Philip is
still on vacation, could someone help notice the release
managers about this plan? Or just help me reach out the
release managers. Many thanks!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Wanming
>>>>>>> On Friday, August 6, 2021 at 3:13:06 AM UTC+8 Chris
Harrelson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Aug 3, 2021 at 9:28 PM Wanming Lin
<wanmi...@intel.com> wrote:
>>>>>>>>> Hi Chris, Daniel and all,
>>>>>>>>>
>>>>>>>>> The blocker issue
https://bugs.chromium.org/p/chromium/issues/detail?id=1209717
has been fixed now, and per above performance improvement
@verwaest reported, can we start testing on Beta again?
>>>>>>>>
>>>>>>>> Sure, go ahead and experiment on canary/dev/beta, and
then come back to us with any new findings.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Saturday, June 12, 2021 at 1:59:25 AM UTC+8
08629...@gmail.com wrote:
>>>>>>>>>> Re:[blink-dev] Ineng to Ship:Remove clamping of set Up
>>>>>>>>>>
>>>>>>>>>> BGODL209B013
>>>>>>>>>>
>>>>>>>>>> ในวันที่ ศ. 11 มิ.ย. 2021 09:13 Wanming Lin
<wanmi...@intel.com> เขียนว่า:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> @verwaest reported at the revert CL that this
change would improve Speedometer2 by 5-6% on the Apple M1 and
~3% on our win10 perf bots. Thanks @verwaest!
>>>>>>>>>>>
>>>>>>>>>>> This is really a good improvement and a new
impetus for us to push this optimization forward. One block at
present is the navigation scheduling issue we reported:
https://bugs.chromium.org/p/chromium/issues/detail?id=1209717,
which has been open for a while and no new updates. Could
someone help to push it? Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Moreover, is there other workaround solution to
push the optimization forward?
>>>>>>>>>>>
>>>>>>>>>>> On Monday, May 17, 2021 at 3:17:48 PM UTC+8
Wanming Lin wrote:
>>>>>>>>>>>> Thanks Chris and Daniel, sorry I didn't explain
clearly for the user reported issue, which is actually a
chrome bug, even with 1ms clamp, this issue may still happen
in some other scenarios, I've created a separated bug and
explained the story at
https://bugs.chromium.org/p/chromium/issues/detail?id=1209717.
PTAL, thanks!
>>>>>>>>>>>> I think it's worth an another intent once this
bug be solved. As it turns out, 1ms' clamp covers up some real
chrome bugs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Friday, May 14, 2021 at 3:44:33 AM UTC+8
Daniel Bratell wrote:
>>>>>>>>>>>>> As Chris said, it's good that you managed to
identify some problematic areas during the beta phase. Of
course it would have been more pleasant with no problems at
all, but this was always a risky change. Hopefully you can use
these bug reports to figure out a version of this change that
doesn't cause those problems.
>>>>>>>>>>>>>
>>>>>>>>>>>>> From a process point of view we will consider
this intent "on hold" until you think it is ready to try
again. At such a time, just return to this thread (or file a
new intent if you think that would be cleaner).
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Daniel
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2021-05-13 19:55, Chris Harrelson wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for these data points. Are these the only
bugs that were filed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd say these bugs are exactly the kind of
interop problems we should be worried about with this intent.
Yes it's true that those sites shouldn't depend on these
relative timings, and it's technically a site bug if so, but
if it is widespread enough it still represents a big enough
problem that it would block shipping this change in behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, May 13, 2021 at 1:24 AM Wanming Lin
<wanmi...@intel.com> wrote:
>>>>>>>>>>>>>> Thank you Philip! We actually received some
regression bugs during initial trial, including several
pinpoint performance regressions and one user reported
scheduling issue. But we finally identify they are all caused
by other issues after investigation. Following's the bug summary:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Pinpoint regressions:
https://bugs.chromium.org/p/chromium/issues/detail?id=1179810
>>>>>>>>>>>>>> We identified the problem is with the perf
story itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. en.wikipedia.org <http://en.wikipedia.org> :
User reports page is scrolled to the top after closing
overlay:
https://bugs.chromium.org/p/chromium/issues/detail?id=1205285
>>>>>>>>>>>>>> This should be an navigation scheduling issue.
>>>>>>>>>>>>>> On Thursday, May 13, 2021 at 3:40:33 PM UTC+8
Philip Jägenstedt wrote:
>>>>>>>>>>>>>>> Hi Wanming,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This change has now been on beta for a time,
and the revert on M91 is in progress. Can you summarize what
you learned from bug reports coming in?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Philip
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Mar 30, 2021 at 5:00 AM Wanming Lin
<wanmi...@intel.com> wrote:
>>>>>>>>>>>>>>>>> Does that sound right to you? If so I can
ask the release managers about this plan.
>>>>>>>>>>>>>>>> Yeah, that sounds good! Thank you for your
support!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Monday, March 29, 2021 at 6:03:04 PM UTC+8
Philip Jägenstedt wrote:
>>>>>>>>>>>>>>>>> Hi Wanming,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the original timeline here won't
work since your CL was reverted and relanded so many times,
and I think I also made a mistake with the branching, since a
change landed after the M90 branch point would never be in the
M90 beta...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To bake in the the M91 beta, what we need to
do is:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Land the change soon before the M91 branch
point, which the latest reland did
>>>>>>>>>>>>>>>>> Allow the change to reach M91 beta (promoted
Apr 22)
>>>>>>>>>>>>>>>>> Revert it on the M91 branch well before the
stable cut/release, let's say May 4 at the latest
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Exactly how much exposure on the beta
channel that will give depends on beta release dates, but it
ought to be at least a week.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Does that sound right to you? If so I can
ask the release managers about this plan.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>> Philip
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Mar 29, 2021 at 4:27 AM Wanming Lin
<wanmi...@intel.com> wrote:
>>>>>>>>>>>>>>>>>> All, the CL has been landed at
https://chromium-review.googlesource.com/c/chromium/src/+/2730350,
sorry for a bit delay due to another reverting during the period.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Philip, could you help to email the release
engineers about this change?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wednesday, February 10, 2021 at 6:14:15
AM UTC+8 Philip Jägenstedt wrote:
>>>>>>>>>>>>>>>>>>> Good idea, Ian, I'll go ahead and do that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Feb 8, 2021 at 5:48 PM Ian
Kilpatrick <ikilp...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>> Philip - if you could also email the
release engineers directly about this change - that likely
would be pertinent (just so this is on their radar in case
things go wrong, and if a revert in Beta is needed).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ian
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Feb 8, 2021 at 1:28 AM Philip
Jägenstedt <foo...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>>> Thanks Wanming, I'll review on the CL.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Can you check back in this thread on the
week of March 22, so that there will be enough time to discuss
before the branch point?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Feb 8, 2021 at 3:07 AM Wanming
Lin <wanmi...@intel.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> Philip, thanks for your comments! I've
submitted the reland CL at
https://chromium-review.googlesource.com/c/chromium/src/+/2636507/,
please take a look.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Saturday, February 6, 2021 at
12:01:24 AM UTC+8 Philip Jägenstedt wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi Wanming,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The most straightforward way to test
this on beta (and canary before that) would be to land the
code right after the M90 branch point (Feb 25) and then revert
it some time well ahead of the M91 branch point (Apr 8). The
beta promotion should be around Mar 11, so you should be able
to get at least a few weeks on beta with this method.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> However, even if the beta baking does
not reveal any issues, breakage due to this can be hard to
understand, and could be in code (libraries) that aren't easy
to update. It would be prudent to make this a finch-controlled
experiment, to avoid a potential urgent revert in a point
release.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> LGTM3 to trying this on beta with
whichever method you prefer at the moment.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>> Philip
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 5, 2021 at 3:34 AM Wanming
Lin <wanmi...@intel.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Thanks Alex, Chris, very glad to see
this great progress!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You have my LGTM1 to flag this on
for Beta for one release, and as we get evidence back from
that, we'd ask you to report it here. On the basis of that
update, we'll then potentially approve a stable launch.
>>>>>>>>>>>>>>>>>>>>>>>> Since I'm new to intent-to-ship
process, could you please guide me or provide BKMs on how to
flag this on for Beta for one release, and what kinds of
testing should be covered? Any chromium program could help
test and evaluate the impact?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Besides, I am thinking of leveraging
chrome://histograms/ to count the use of setTimeout(..., 0)
from some hot websites, then we can do some basic testing to
check if there's obvious regression. Does it make sense?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Wanming
>>>>>>>>>>>>>>>>>>>>>>>> On Friday, February 5, 2021 at
4:16:37 AM UTC+8 Chris Harrelson wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> LGTM2 for testing on beta and coming
back to the API owners with the results.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 4, 2021 at 12:15 PM Alex
Russell <sligh...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the clarification,
Geoffery.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Wanming: we discussed this again at
today's API OWNERS meeting and, given what Mike and Ben noted
here, we'd like to see this bake for a while on Beta to shake
out any potential compat issues. You have my LGTM1 to flag
this on for Beta for one release, and as we get evidence back
from that, we'd ask you to report it here. On the basis of
that update, we'll then potentially approve a stable launch.
Does that sound good to you?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Also, if you have any more data as
to why this change improves things for users and developers,
that would also be helpful.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, February 1, 2021 at
12:01:42 PM UTC-8 geoffrey garen wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note:
http://trac.webkit.org/changeset/17156/webkit is not the
change that added the minimum timeout clamp. r17156 *reduced*
a pre-existing 10ms clamp to 1ms.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, January 29, 2021 at
7:22:28 AM UTC-8 wande...@chromium.org wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also note that if you nest
setTimeout(..., 0) enough (5 times?) then you start getting
4ms clamping anyway. So this is really about the first 4 or so
setTimeout(..., 0) calls in a chain. I don't think this intent
is removing the 4ms clamping for nested timeouts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2021 at 10:20 AM
Ben Kelly <wande...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Its possible folks are using
setTimeout(.., 0) as a setImmediate() replacement which would
result in high numbers. But that use case would not be
adversely impacted by removing this clamping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2021 at 4:01 AM
Yoav Weiss <yo...@yoav.ws> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2021 at 9:54 AM
Wanming Lin <wanmi...@intel.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks all for your comments!
I've created a WebKit issue at:
https://bugs.webkit.org/show_bug.cgi?id=221124
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The main motivation of this
intent-to-ship is to correct the scheduling and reduce
potential performance impact. We didn't find impact on live
sites with/without 1ms clamp maybe they‘ve already avoided the
usage of setTimeout(..., 0) since compatible risk is really
existed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do we have numbers on how often
`setTimout(... ,0)` is used? (use counters, HTTPArchive,
cluster telemetry, etc)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What about setInterval?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since remove 1ms clamp exits
risk, we'd like to change setTimeout at first and base on
discussion result to see if it's reasonable, if yes, we can
apply it at setInterval as next step.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, January 29, 2021 at
6:14:07 AM UTC+8 Mike Taylor wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Howdy,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In general, I think if
Firefox has been able to ship this behavior it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> likely web-compatible (modulo
different code paths being served behind
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UA sniffing).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There have been subtle race-y
JS timing bug differences between sites in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Firefox and Chrome that my
old team (at Mozilla) looked at, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unfortunately I don't have
any links to back that up. So there is some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> risk that sites are
(unintentionally) relying on the old behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That said, aligning with
Firefox (and the HTML standard) on this seems
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> good -- more so if WebKit is
willing to do so as well.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A few questions:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What about setInterval?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Will setTimeout and
setInterval be consistent wrt clamping after this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposed change? (see also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
https://bugzilla.mozilla.org/show_bug.cgi?id=1646799#c0)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/28/21 2:28 PM, Alex
Russell wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +mike taylor who may have
insight into the potential compat risks, given
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the different behavior
between Gecko and WebKit/Blink.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, January 28,
2021 at 4:53:47 AM UTC-8 Manuel Rego wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 27/01/2021 03:01, Lin,
Wanming wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Safari: 1ms clamp (WebKit's
clamp at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384>>)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have we checked with WebKit
if they have any plans to change this or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at some point? Is there a
WebKit bug report or something?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe you can ask for
signals in webkit-dev, see
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bit.ly/blink-signals
<https://bit.ly/blink-signals>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bye,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Rego
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You received this message
because you are subscribed to the Google
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Groups "blink-dev" group.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this
group and stop receiving emails from it, send
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an email to
blink-dev+...@chromium.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<mailto:blink-dev+...@chromium.org>.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To view this discussion on
the web visit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org?utm_medium=email&utm_source=footer
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org?utm_medium=email&utm_source=footer>>.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You received this message
because you are subscribed to the Google Groups "blink-dev"
group.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this group
and stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To view this discussion on the
web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c1d6691-1ccd-4451-a491-56990ecc695fn%40chromium.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You received this message
because you are subscribed to the Google Groups "blink-dev"
group.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this group
and stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To view this discussion on the
web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhAvLduQ6XXA-Vm-8%3DTM9L-d5q1_h-DrvrKLHg8NBvxEQ%40mail.gmail.com.
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> You received this message because
you are subscribed to the Google Groups "blink-dev" group.
>>>>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this group and
stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> To view this discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/095fc193-27e5-4a7c-b816-edbab7eb176cn%40chromium.org.
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> You received this message because you
are subscribed to the Google Groups "blink-dev" group.
>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfU0La%3D3Fpd%3DHBVQ2phHuvMSozpOsXqt-NR-mtWepRJPQ%40mail.gmail.com.
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> You received this message because you are
subscribed to the Google Groups "blink-dev" group.
>>>>>>>>>>>>>> To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2869319d-e852-4f3b-8471-611f6ae7c9b4n%40chromium.org.
>>>>>>>>>>>>> --
>>>>>>>>>>>>> You received this message because you are
subscribed to the Google Groups "blink-dev" group.
>>>>>>>>>>>>> To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+...@chromium.org.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8JUEZDbfNsmXJWhcz_N7zcRwzoips2r_DzMEqhctwr1g%40mail.gmail.com.
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are
subscribed to the Google Groups "blink-dev" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving
emails from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>>>
>>>>>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b155d685-4b7e-498b-8e8a-1e9c95d4195an%40chromium.org.
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed
to the Google Groups "blink-dev" group.
>>>>>>>>> To unsubscribe from this group and stop receiving
emails from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>
>>>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2f1d2cf-0b9b-4ed4-ac0e-4f7d9a20e4c1n%40chromium.org.
>>>>>>> --
>>>>>>> You received this message because you are subscribed
to the Google Groups "blink-dev" group.
>>>>>>> To unsubscribe from this group and stop receiving
emails from it, send an email to blink-dev+...@chromium.org.
>>>>>>> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb9aacdf-dc28-42b0-90cd-6c0faec080ffn%40chromium.org.
--
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/5c0e9914-2d52-4e08-b041-c9ee4d5042cdn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0e9914-2d52-4e08-b041-c9ee4d5042cdn%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/CAL5BFfVtUZ63ZiiCLcFCYD2%2BnpOrt3g0anJQ3R-to0x%3DbNG_9A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVtUZ63ZiiCLcFCYD2%2BnpOrt3g0anJQ3R-to0x%3DbNG_9A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
