I assume the idea is that this would be Finch controlled in Chrome? That sounds like a good idea if so! Do we have good docs for what's needed to make something possible to control with Finch?
On Fri, Oct 15, 2021 at 8:17 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Apologies for not being clearer, but this intent is not yet approved. > > Talking about this with the API owners yesterday, we still see potentially > high compat risk here, while at the same time there are potential > compatibility and performance benefits. > One thing that was brought up was that this should be behind a feature > flag, so that the various Chromium browsers would be able to carefully roll > this out, and at worst, be able to turn it off if needed. > > On Fri, Oct 15, 2021 at 3:32 AM Wanming Lin <wanming....@intel.com> wrote: > >> Thanks again! So can I suppose I have your LGTMs now and be approved to >> proceed the final ship to M97? >> >> On Friday, October 15, 2021 at 12:15:08 AM UTC+8 jste...@chromium.org >> wrote: >> >>> M97 is also a better alternative in that it's not a release that will be >>> supported for 8 weeks, as M96 would be, and thus we'll be in a better >>> position to handle any fallout from this in M97. >>> >>> On Thu, Oct 14, 2021 at 6:32 AM Mike Taylor <mike...@chromium.org> >>> wrote: >>> >>>> Ah, yeah. I think I intended to write M97 (but I'm admittedly terrible >>>> with calendars). That seems like a good milestone to try to ship. >>>> >>>> On 10/14/21 5:01 AM, Yoav Weiss wrote: >>>> >>>> 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 <wanmi...@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 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. >>>>> >>>>> >>>> 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 : 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+...@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+...@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> >>>> . >>>> >>>> >>>> -- >>>> 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/6d9cd96f-fd70-83bf-63cb-985fa7c27b07%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6d9cd96f-fd70-83bf-63cb-985fa7c27b07%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/CAARdPYc%2B40PtLd5H9%3DLJpSyu9QDHAuoahyUbR7YXz4qyH1%2BELw%40mail.gmail.com.
