Thanks for chiming in, Brandon! I'm glad to hear that the Enterprise constituency is comfortable with the plan. I'm concerned that there may be a couple other constituencies that may not be:
- Third party widgets that currently use unload to send a single "end of page" beacon. fetchLater() <https://github.com/WICG/pending-beacon> is aiming to be that replacement, but it's not ready just yet. - Enterprise SAAS providers that don't have direct and immediate control over their customers' application configuration, nor on their users' Enterprise Policy. I think that a short-lived 3P deprecation trial may address these constituencies as well. Would you consider adding that to your plans? On Sat, Jul 8, 2023 at 12:55 AM 'Brandon Heenan' via blink-dev < blink-dev@chromium.org> wrote: > Hello, I'm chiming in to provide some thoughts from the enterprise > perspective. > > Our goal is to not block forward progress to the web, but to improve the > web in an enterprise-friendly way. You shouldn't ever hear me say "you > can't do X because it's scary to the enterprise team." You should instead > hear "We expect X to be risky, but here are the things we know we can do to > make it much less risky." > > In this case, yes, this is risky for enterprises. We can say this with > confidence because we've seen escalations before when we've made changes to > unload events (crbug.com/933153, crbug.com/953228). > > Kenji and Daisuke have been working with us, and my understanding of the > plan is to: > > - > > Allow developers to opt-in early to the new behavior (unload event > ignored) with a permission policy > - > > Communicate the change on chromestatus and the enterprise release > notes (already happening > > <https://support.google.com/chrome/a/answer/7679408?sjid=15316582819754370342-NA#skpUnload114>). > We will provide a bug link for customers for feedback in a future release. > - > > Reach out to enterprises and developers we expect to be affected > - > > Introduce an enterprise policy to allow an IT admin to control unload > event behavior > - > > Introduce a flag in chrome://flags/deprecated to allow end users to > control unload event behavior > - > > As early as M117, change the default for the policy so that unload > events will be ignored. This is the breaking change, and there's likely to > be friction here. The two escalations mentioned above both resulted in > respins the first time they reached this point. However, this time around, > IT admins will be able to fix their environment immediately with the > enterprise policy, end users will be able to fix themselves with the > deprecation flag, and developers will be able to fix their app with the > permission policy. With those mitigations in place, the risk of requiring a > respin (or Finch rollback) due to enterprise impact is dramatically > reduced, and this is how we eventually successfully shipped both of those > above escalations. > - > > We expect a long transition period after that. By default, the unload > event is ignored, but different stakeholders are able to revert to legacy > behavior. Within enterprise, we expect the enterprise policy to be the most > useful mitigation, and the deprecation flag is the backup for BYOD or > unmanaged devices. For the above escalations, this migration period was > over a year, and I'm expecting something similar this time. > - > > At some point in the future, we expect to remove those mitigations and > remove support for the unload event completely. We don't have any specific > dates for that yet; we will be responsive to the needs of web stakeholders, > enterprise and otherwise. > > The two escalations I mentioned above were successfully resolved and the > changes to not allow popups on page unload and to not allow synchronous > XHRs on page unload were shipped. Both of those changes followed > essentially the same plan I just laid out above, and so I think it's > reasonable to do the same thing here. > > > On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote: > >> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux <kenji...@google.com> wrote: >> >>> >>> On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly <fer...@google.com> wrote: >>> >>>> On Thu, 29 Jun 2023 at 01:16, Rick Byers <rby...@chromium.org> wrote: >>>> >>>>> Hi Fergal, >>>>> Thanks for pushing through this contentious and challenging >>>>> deprecation. We discussed this in the API owners meeting today and were >>>>> worried that this plan seemed likely to be seriously problematic for >>>>> enterprises (policy opt-out is helpful, but far from a silver bullet >>>>> unfortunately). To what extent have you engaged with them and worked to >>>>> follow the enterprise breaking change policy >>>>> <https://www.chromium.org/developers/enterprise-changes/>? Our hunch >>>>> is that at 1% or 5% we'd get escalations forcing us to abandon this plan. >>>>> Of course, if the enterprise team is OK with it, we could always try >>>>> anyway >>>>> and see if our hunch is right. It's possible I'm over-indexing on past >>>>> experiences like deprecating sync XHR in unload handlers >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/LnqwTCiT9Gs/m/tO0IBO4PAwAJ> >>>>> and that the enterprise world is different now, but I doubt it :-). >>>>> >>>> >>>> In addition to Daisuke's response... are you concerned about >>>> enterprises that are not using fleet management and so cannot use the >>>> opt-out? If you think an enterprise policy will not be sufficient, a >>>> mitigation for those enterprises would be for us to publish an extension >>>> that allows anyone to re-enable unload (for all sites or for specific >>>> sites) by injecting the PP:unload header. Are the escalations that can't be >>>> resolved by either a policy or extension? >>>> >>> >>> One extra comment on the extension option (great for desktop). >>> >>> If you wonder about the mobile BYOD scenarios, where extensions don't >>> exist, then we are a bit lucky here because unload is already unreliable on >>> mobile. So, it seems extremely unlikely that we'd see mobile enterprise/edu >>> products that rely on unload on mobile. >>> >>> *Rick:* are there specific scenarios / environments that we haven't >>> covered? >>> >> >> I'm glad to see the conversation with the enterprise team is further >> along than I had realized. Having skip unload events in the release notes >> <https://support.google.com/chrome/a/answer/7679408?sjid=5091298988245423514-NA#skpUnloadEv113> >> since M113 is a significant mitigation, sorry I wasn't caught up on the >> latest. And yes some sort of user opt-out for BYOD (extension or >> chrome::/flags, etc.) seems like an essential mitigation. I defer to the >> enterprise team's judgement here, so if they're OK with proceeding then we >> shouldn't let my enterprise fears block us. I expect we do need some easy >> way for an application to signal that it really does need unload handlers. >> Setting a permission policy is likely orders of magnitude easier than >> converting essential unload handlers to pagehide and ensuring they're safe >> to invoke multiple times. >> >> The other major constituency potentially impacted are ad networks. >> Perhaps the next step should be a 1% finch trial where we can measure >> various ad-related metrics? I'd defer to the judgment of the Chrome Ads >> team (@Josh Karlin). >> >> Anyway, I'm personally OK with 1% stable experiments (and whatever else >> on dev/beta). But I think we should discussing learnings from such 1% >> experiments here publicly before approving a plan to go beyond that. >> >> In general Yoav and I disagree with the WebKit and Gecko feedback here >>>>> and suspect that your original PP default-on proposal is far more likely >>>>> to >>>>> be a successful deprecation path for Chrome (and, should they choose to >>>>> follow, Edge). I can understand why Firefox and WebKit don't have the same >>>>> constraints around enterprises and so would choose differently for >>>>> themselves. Yoav and I are happy to help in the standards discussions. I'm >>>>> about to go on vacation for 2 weeks but Yoav said he'd follow up with you >>>>> privately to brainstorm next steps. Sound good? >>>>> >>>> >>>> I would love to get moving on PP:unload ASAP no matter what. It's been >>>> through OT and is sitting behind a flag with some sites eager to use it. >>>> I'm happy to send an I2S for that while we discuss the harder problem. We >>>> hope that getting that out there can clear out a large chunk of the 1st- >>>> and 3rd-party unload usage, >>>> >>> >>> +1, I'd suggest doing that regardless. >>> >>> There are a few large sites that have done some legwork on >>> unload handlers (theirs and third party partners), and are interested in >>> pushing the remaining unload handlers out with PP:unload. Having allies in >>> the ecosystem (i.e. extra incentives to migrate), will be helpful going >>> forward :) >>> >> >> Yep I think this was Yoav and my primary concern. For chrome to have a >> pragmatic and reasonable deprecation path given our user base, we really >> need sites adopting such an API. If we're not going to actually ship such >> an API then I think we'd have to give up on deprecating unload. I'd support >> shipping this API despite the lack of support from WebKit and Gecko. >> >> >>> F >>>> >>>> >>>>> >>>>> Rick >>>>> >>>>> >>>>> On Wed, Jun 28, 2023 at 4:07 AM Fergal Daly <fer...@google.com> wrote: >>>>> >>>>>> Hi API-owners, >>>>>> >>>>>> >>>>>> I am now asking for permission to go ahead with the following >>>>>> concrete unload deprecation plan below. >>>>>> >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> Tools and outreach >>>>>> - >>>>>> >>>>>> M115 Enable `Permission-Policy: unload` (PP:unload) with the >>>>>> default being enabled. This allows sites to opt-in to unload >>>>>> deprecation. >>>>>> - >>>>>> >>>>>> Outreach to 1st/3rd parties, to migrate away from using unload >>>>>> and to enforce this with PP:unload. >>>>>> - >>>>>> >>>>>> Deprecation >>>>>> - >>>>>> >>>>>> M117 change the default for PP:unload so that unload handlers >>>>>> are skipped by default for 1% of page loads >>>>>> - >>>>>> >>>>>> M118 increase to 5% of page loads >>>>>> - >>>>>> >>>>>> M119 (last of 2023) increase to 10% of page loads >>>>>> - >>>>>> >>>>>> Evaluate progress on reduction of the use of unload >>>>>> - >>>>>> >>>>>> M120-128 increase +10% gradually to 100% of page loads >>>>>> >>>>>> >>>>>> Enterprise policy would allow opt-out entirely. >>>>>> >>>>>> >>>>>> Obviously, the deprecation timeline is contingent on unload usage >>>>>> coming down in response to the earlier steps. >>>>>> >>>>>> We expect that 10% of page loads will provide a noticeable signal to >>>>>> sites that use unload. Also, if we were to just follow the current spec >>>>>> and >>>>>> not run unload when we can BFCache (as happens on Clank/Firefox mobile >>>>>> and >>>>>> all WebKit) we expect that we would skip 30-40% of unload handlers when >>>>>> the >>>>>> main frame navigates. >>>>>> >>>>>> Decisions: >>>>>> >>>>>> - >>>>>> >>>>>> Timeline >>>>>> - >>>>>> >>>>>> All navigations vs main-frame navigations only >>>>>> >>>>>> >>>>>> Standardising >>>>>> >>>>>> We have some new data and have had some further discussions with >>>>>> browser vendors. There's no consensus. TL;DR WebKit are opposed to any >>>>>> Permissions-Policy but support removing unload eventually. Mozilla are >>>>>> still discussing. >>>>>> >>>>>> Both Mozilla >>>>>> <https://github.com/mozilla/standards-positions/issues/691> and >>>>>> WebKit <https://github.com/WebKit/standards-positions/issues/127> >>>>>> were opposed to standardising `Permissions-Policy: unload` (defaulting to >>>>>> on) because they worried that a containing frame might selectively >>>>>> disable >>>>>> unload handlers in a child frame for malicious purposes (no specific >>>>>> cases >>>>>> were discussed). >>>>>> >>>>>> So we flipped to the idea of having PP:unload with the default being >>>>>> disabled. We cannot suddenly do that. We need to roll it out gradually. >>>>>> WebKit folks are opposed to this and have suggested >>>>>> <https://github.com/WebKit/standards-positions/issues/200#issuecomment-1596385073> >>>>>> we do a reverse origin trial instead. If our plan works out, eventually >>>>>> we >>>>>> would ROT as the final nail but ROT starting now has downsides for users >>>>>> and sites and no upside for the implementer. >>>>>> >>>>>> Mozilla has so far not been negative >>>>>> <https://github.com/mozilla/standards-positions/issues/691> on the >>>>>> Permissions-Policy off-by-default approach but they are still discussing. >>>>>> They are concerned that disabling unloads when subframes are navigating >>>>>> could be a problem. We found that about 1/4 of subframe navigations >>>>>> involve >>>>>> an `unload` handler (most seem to involve handlers in cross-site and >>>>>> same-site site frames). We don't have examples of sites that rely on >>>>>> `unload` handlers in this way, although they probably do exist. Migrating >>>>>> to `pageshow` or using PP:unload for these sites should be trivial. >>>>>> >>>>>> We have the option to say that PP:unload only applies to main frame >>>>>> navigations. This would mean these sites would be completely unaffected >>>>>> however that has some downsides. It is harder to explain and does not end >>>>>> with full removal of `unload`. We would prefer to have this apply to all >>>>>> navigations unless we find a good reason not to. If we were to change >>>>>> part-way, there would be no breakage. We hope that once we drive down >>>>>> usage >>>>>> in 3rd-part iframes with PP:unload that the number of unload handlers >>>>>> running in subframe navigations decreases significantly. >>>>>> >>>>>> Finally there was some discussion >>>>>> <https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739> >>>>>> about how Permissions-Policy off-by-default should work. Our current >>>>>> version requires every page to set the header and every parent to set the >>>>>> iframe `allow` attribute. This is maximally conservative. If at some >>>>>> point >>>>>> later on there is agreement to standardise on something less >>>>>> conservative, >>>>>> it will not break pages that have already re-enabled `unload`. >>>>>> >>>>>> >>>>>> Overall it seems hard to standardise in advance but if we succeed in >>>>>> driving down `unload` usage, other browsers are on-board with removing >>>>>> unload. The worst case scenario would be where we implement PP:unload >>>>>> (which the others do not agree with) but make no noticeable progress on >>>>>> `unload` usage. If that happens we can just go with the currently specced >>>>>> behaviour (don't run `unload` if BFCaching is possible) and maybe revert >>>>>> the PP:unload, >>>>>> >>>>>> F >>>>>> >>>>>> On Tue, 9 May 2023 at 16:01, Fergal Daly <fer...@google.com> wrote: >>>>>> >>>>>>> On Mon, 8 May 2023 at 17:51, Rick Byers <rby...@chromium.org> wrote: >>>>>>> >>>>>>>> Hi Fergal, >>>>>>>> It's exciting to see this moving forward! Just to clarify, this is >>>>>>>> effectively an I2S for the unload permissions-policy, is that right? >>>>>>>> Or are >>>>>>>> you also requesting permission to stop firing unload events now too? >>>>>>>> The >>>>>>>> latter is going to require some significant compat analysis, but could >>>>>>>> be >>>>>>>> greatly informed by the experience of having some top-level sites >>>>>>>> opt-out >>>>>>>> of unload for their frame tree. >>>>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> We're not requesting permission to stop firing at this point. It is >>>>>>> the far-away end-point. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Any plan to trigger a deprecation warning / report for the >>>>>>>> installation of unload handlers? It might be tricky to find a good >>>>>>>> balance >>>>>>>> of useful warnings without being too spammy. >>>>>>>> >>>>>>> >>>>>>> Permission policy will do this as is with a console warning and >>>>>>> Reporting-API if you attempt to install a handler that is disallowed by >>>>>>> policy. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> A couple more questions / comments inline: >>>>>>>> >>>>>>>> On Mon, May 8, 2023 at 7:43 AM Fergal Daly <fer...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> fer...@chromium.org, kenji...@chromium.org >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://github.com/whatwg/html/pull/7915 >>>>>>>>> >>>>>>>> >>>>>>>> This is still marked as draft. Can you get this ready for review? >>>>>>>> If it's blocked only on having a 2nd implementor show support, then >>>>>>>> I'd be >>>>>>>> fine shipping based on a PR. But we should at least do what we can to >>>>>>>> solicit feedback on the spec change prior to shipping. >>>>>>>> >>>>>>> >>>>>>> Yes. There's nothing in the spec change that isn't in the requests >>>>>>> for positions but since neither of those are supportive yet, I have not >>>>>>> asked for review of the PR. I'm hopeful that once we have data on use on >>>>>>> unload in subframe navigations as discussed here >>>>>>> <https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320> >>>>>>> that >>>>>>> Mozilla will be supportive. Those metrics are in 113 but based on the >>>>>>> data >>>>>>> from beta, we need to change how we record them. >>>>>>> >>>>>>> >>>>>>>> Summary >>>>>>>>> >>>>>>>>> A Permission-Policy for creating unload event listeners will be >>>>>>>>> added. >>>>>>>>> >>>>>>>>> Initially, the default policy will be set to allow. From there, >>>>>>>>> Chrome will gradually migrate the default policy to deny (i.e. >>>>>>>>> increasingly disallow the creation of unload event listeners, >>>>>>>>> eventually >>>>>>>>> reaching a state where deny fully becomes the default policy). >>>>>>>>> The ultimate goal is to remove support for unload event. >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>PermissionsAPI >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> >>>>>>>>> >>>>>>>>> Motivation >>>>>>>>> >>>>>>>>> The unload event is extremely unreliable. It is ignored in most >>>>>>>>> cases by all mobile browsers except Firefox on Android. Furthermore, >>>>>>>>> in >>>>>>>>> Safari, the unload event is ignored on both desktop & mobile >>>>>>>>> platforms. >>>>>>>>> >>>>>>>>> In the current state, unload is a major BFCache blocker (~18 >>>>>>>>> percentage points reduction of hit rate for Chrome). >>>>>>>>> >>>>>>>>> The change will unlock a large fraction of that hit-rate while >>>>>>>>> providing an opt-out for those who need more time to migrate. It also >>>>>>>>> sends >>>>>>>>> a clear signal that unload should not be used in new development. >>>>>>>>> >>>>>>>>> Sidenote: the spec was changed to say that unload should only run >>>>>>>>> if the page cannot enter BFCache, which reflects Safari’s behavior, >>>>>>>>> However >>>>>>>>> neither Chrome nor Mozilla have implemented this behavior. In Chrome's >>>>>>>>> case, we believe that this would suddenly break various sites and >>>>>>>>> would >>>>>>>>> make it hard for developers to know if/when unload may run. >>>>>>>>> >>>>>>>>> >>>>>>>>> Initial public proposal >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/738 >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Pending >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> If no other browsers implement this, there is a risk that devs >>>>>>>>> continue to use unload widely and pages malfunction on chrome. However >>>>>>>>> given that alternatives to unload exist it seems entirely possible for >>>>>>>>> sites that are actively maintained to move off unload. >>>>>>>>> >>>>>>>>> Gecko: ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320) >>>>>>>>> It's possible that pages are depending on `unload` handlers in >>>>>>>>> subframes >>>>>>>>> for functionality even without any main frame navigation. We should >>>>>>>>> try to >>>>>>>>> understand how common this is before breaking it. It should be >>>>>>>>> possible to >>>>>>>>> measure how often subframe unloads fire when the mainframe is not >>>>>>>>> navigating. This will give us an upper bound on the size of the >>>>>>>>> problem, - >>>>>>>>> Chrome: we have landed code to measure the occurrence of unload in >>>>>>>>> different scenarios. We will report back the findings. >>>>>>>>> >>>>>>>>> WebKit: https://github.com/WebKit/standards-positions/issues/127 >>>>>>>>> >>>>>>>> >>>>>>>> From a quick skim, it sounds like WebKit is already happy with >>>>>>>> their tradeoff of not firing unload and doesn't see a need for an API >>>>>>>> that >>>>>>>> reduces unload further, is that about right? WebKit has mostly shipped >>>>>>>> heuristics here without trying to spec them first, right? In general >>>>>>>> I'm >>>>>>>> not too concerned >>>>>>>> >>>>>>> >>>>>>> Yes, there's no great upside for them. I believe the situation as >>>>>>> specced where unload is unpredictable and likely biased is bad for devs >>>>>>> and >>>>>>> is probably skewing data collected via WebKit (and Chrome/Mozilla >>>>>>> mobile) >>>>>>> but nobody is complaining. >>>>>>> >>>>>>> I believe there was support expressed offline for the prospect of >>>>>>> killing off unload. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Web developers: Positive ( >>>>>>>>> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ) >>>>>>>>> The web communities we reached out had positive reactions to our >>>>>>>>> proposal >>>>>>>>> and we have not heard about any concrete blockers. >>>>>>>>> >>>>>>>>> Other signals: >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? >>>>>>>>> >>>>>>>>> On WebView, we will introduce the Permissions-Policy but not move >>>>>>>>> the default to "deny". BFCache does not work on WebView, so the >>>>>>>>> benefit is >>>>>>>>> lower. Meanwhile the risk seems higher as we have far less visibility >>>>>>>>> into >>>>>>>>> the HTML being run in WebViews. A roll-out to WebView should be done >>>>>>>>> independently and in consultation with the WebView team. >>>>>>>>> >>>>>>>> >>>>>>>> Sounds like the right strategy to me, thanks! >>>>>>>> >>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> Flag name >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>> >>>>>>>> Please put the new policy behind a RuntimeEnabledFeature >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>. >>>>>>>> It's effectively a new API so is required >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >>>>>>>> to have a finch killswitch. It sounds to me like it should be unlikely >>>>>>>> that >>>>>>>> simply adding the new policy could break things, but maybe some >>>>>>>> scenario is >>>>>>>> possible where we decide breakage in 3p iframes is bad enough to >>>>>>>> warrant an >>>>>>>> emergency fix? >>>>>>>> >>>>>>> >>>>>>> Yes, there will be a flag, maybe more than one. The implementation >>>>>>> details of rolling this out gradually have not been worked out. See >>>>>>> below. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> False >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> M115 for availability of Permissions-Policy >>>>>>>>> >>>>>>>>> M115 is the earliest we would start to disable unload, however >>>>>>>>> >>>>>>>> >>>>>>>> Is this a typo? Or are you considering disabling the event in the >>>>>>>> same release we first make the permissions policy available? >>>>>>>> >>>>>>> >>>>>>> The plan is to make the PP available with a default of enabled and >>>>>>> then gradually flip the default to disabled. The details are here >>>>>>> <https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#logistics-of-deprecation>. >>>>>>> It's not particularly nice. We have the option to just stop 100% but >>>>>>> that >>>>>>> seems fairly disruptive, >>>>>>> >>>>>>> F >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5579556305502208 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>> >>> -- >>> Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) >>> Product Manager - Chrome >>> Google Japan >>> >> -- > 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/d955dd04-7aac-462a-bd85-d69df8d7d86bn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d955dd04-7aac-462a-bd85-d69df8d7d86bn%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/CAL5BFfXmyTqHwD0VWSNeVv8ZaY8HQ5KDdkqRBO-8hy%2BPkK6OJw%40mail.gmail.com.
