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.