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 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, 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.
> >>
> >>
> >> 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, the original bug on Wikipedia has been fixed on 
> Wikipedia's side.
> >>>>
> >>>> 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 : 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
> >.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.

Reply via email to