That sounds like a good idea to me, if release managers are OK with it. Differences between beta and stable are always a risk, after all.
Wanming, what do you think about this approach? On Fri, Oct 15, 2021 at 4:43 PM Chris Harrelson <chris...@chromium.org> wrote: > 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/CAARdPYeAb1eNWW2vhndyQ6gVKFaqeR7weBbcaVKnU5OoxCan%2BQ%40mail.gmail.com.
