Hi Wanming, My team can help out with this (I work on scheduling APIs). I'll send an email off-thread so we can coordinate. Thanks for working on this!
- Scott On Fri, Oct 15, 2021 at 8:58 AM Wanming Lin <wanming....@intel.com> wrote: > Thanks all! Absolutely, we should be very careful for shipping this > change, I'm totally agree with this approach. > > Could you guide me how to control it via finch? Is there any docs? > > On Friday, October 15, 2021 at 11:34:10 PM UTC+8 Philip Jägenstedt wrote: > >> 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 <chri...@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 <yoav...@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 <yoav...@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 <wanmi...@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+...@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/dec6a8e0-14c3-44e4-851c-66f95a370238n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dec6a8e0-14c3-44e4-851c-66f95a370238n%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/CAKXGoJ21%3DOQWdc5-Y9Qt72KyrAfFk7029Kj7ozyX%3DNasB52_CA%40mail.gmail.com.
