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 <miketa...@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 <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 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+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> > . > > > -- > 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/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/CACZRgz6%3DyJf_57pE6STun_FeX%2BPZ5ajXNgOB5J3WpodPPY-ANA%40mail.gmail.com.
