How about this option: put it behind a feature flag, and turn it on via finch for canary, dev and beta channels. Then let it run for several releases, gathering additional feedback on bugs in order to increase confidence.
On Thu, Oct 14, 2021 at 11:55 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > I believe it's just a matter of adding a feature flag > <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/how_to_add_your_feature_flag.md#step-1_adding-a-new>, > and making sure that the feature is off when it's disabled. Then Chrome can > create a Finch configuration based on that, Edge can set up its own > controls, etc. > > It may be reasonable to have the feature flag off by default, and have > server-side configs that turn it on. (e.g. I believe enterprise users may > opt-out of such configs, so it's better to be cautious there and have the > risky option enabled by configs, rather than disabled by it) > That would mean that we'd need engineers on the Chrome and Edge side of > things to own the configs that turn this on. > > On Fri, Oct 15, 2021 at 8:41 AM Philip Jägenstedt <foo...@chromium.org> > wrote: > >> 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/CAL5BFfX2K1V0CXc1Z%3DKJ_BUZ2MsZVmgzX0DfOkjZO1Lm7-NqnA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX2K1V0CXc1Z%3DKJ_BUZ2MsZVmgzX0DfOkjZO1Lm7-NqnA%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/CAOMQ%2Bw-Tr36ktWrzWtuTW%3DDiy0adL-N7x4chXBRsBpYtc1uEVA%40mail.gmail.com.
