Thanks for weighing in Barry! I was previously leaning to preferring #2 myself but you've all changed my mind. #3 (Fergal's request) now definitely sounds better to me too. Thanks!
Although it's not tracked in chromestatus as a separate thing, I think we should get 2 additional API owners to approve the plan. Yoav, WDYT? Rick On Tue, Jan 20, 2026 at 11:00 AM Barry Pollard <[email protected]> wrote: > I'd argue it's already non-deterministic in many cases including: > 1) Mobile on all platforms > 2) Safari > Where unload runs intermittently. So if site behaviour currently depends > on unload, then it's already broken in these cases. > > And I admire the push here to end up in a deterministic state for Chrome > (where it's fully deprecated, rather than just "more unreliable") and > hopefully all of the web platform after that. > > But yes it is (currently) reasonably reliable on Chrome desktop, so there > is potential pain to get there. Especially for more desktop app sites that > are potentially less used on mobile (either because there is a mobile app > used by a large proportion of those visitors, or because the form-factor > makes it less likely that that particular app is used on mobile). > > So back to the choices: > 1. I agree with Yoav, that this "means that the pain is felt by the folks > with the least agency of resolving it." > 2. Does put the pressure on the sites (or the third-parties they use) but > in a nondeterministic fashion. If anything we'd be better continuing the > top 50 rollout when doing this (to top 100, top 1,000, top 10,000...etc) > but that's not that much more deterministic and likely a lot of hassle. > 3. Is more random. Which I agree has problems. But on the other hand is > also more in the spirit of a gradual roll out we'd do for other things even > if they have potential to break things. > > So, from a DevRel point of view, I favour 3 despite that randomness. Which > IIUC is what Fergal was proposing? And no I hadn't discussed this with him > before so this is just my thoughts from reading this thread. > > I also agree that expectations of breakage are low, based on what we've > seen so far in top 50. I suspect most usage will be in relation to > third-parties and/or tracking scripts rather than a loss in main-site > functionality to the user. Which may still be important to the site owner > or user, but is less likely to need an immediate fix. But it's a big change > so difficult to state that with any degree of certainty. > > > On Tue, 20 Jan 2026 at 15:32, Rick Byers <[email protected]> wrote: > >> Thanks for the explanation, Fergal. Any signal from WEC and/or DevRel on >> which approach developers would prefer? On the one hand if we do a >> user-based staged rollout then it makes the impact gradual for them >> (lessening the risk and giving them more time to adapt while it ramps up), >> but it also increases the risk that some poor developers waste a lot of >> time trying to debug a (to them) non-deterministic behavior. I'm guessing >> if we asked developers who were familiar they'd say they prefer a gradual >> ramp for their site to minimize risk, but if we could somehow survey all >> the developers who have no idea this is coming they might say they prefer >> the more deterministic approach so that they can quickly understand and >> mitigate it? >> >> What's your plan for pre-stable channels? Maybe we're nearing the point >> that Canary/Dev users shouldn't get unload events at all? >> >> Thanks, >> Rick >> >> On Tue, Jan 20, 2026 at 6:24 AM Yoav Weiss (@Shopify) < >> [email protected]> wrote: >> >>> #1 means that the pain is felt by the folks with the least agency of >>> resolving it.. >>> >>> #2 at least feels like there's a better chance sites will wean off their >>> use of unload events, apply pressure on third parties and/or file Chromium >>> bugs. >>> >>> On Tue, Jan 20, 2026 at 1:42 AM Fergal Daly <[email protected]> wrote: >>> >>>> On Tue, 20 Jan 2026 at 06:37, Rick Byers <[email protected]> wrote: >>>> >>>>> Hi Fergal, >>>>> This is exciting and (of course) a little scary. But thank you for all >>>>> the care you've put into this, and for the close partnership on outreach >>>>> with the WEC team. I trust you all to manage the rest of the rollout with >>>>> the same care. LGTM1 to proceed >>>>> >>>>> I do have a question though. I thought the point of focusing on >>>>> origin-based rollouts was to avoid the pain for web-developers of being >>>>> confused why some users are seeing different behavior (with the same >>>>> Chrome >>>>> version) than others? If I understand correctly, the rollout plan now >>>>> includes both a per-origin and per-user component, is that right? Again I >>>>> trust you to manage this, just curious to understand how much we can >>>>> expect >>>>> to avoid the pain of A/B experiments on major web-visible behavior within >>>>> a >>>>> single origin. >>>>> >>>> >>>> I have wavered on this multiple times and am leaning towards changing >>>> it. >>>> >>>> There's no great way to do this. We have 3 choices (that I can think >>>> of): >>>> 1 we can give N% of users deprecation on 100% of sites >>>> 2 we can give N% of sites deprecation for 100% of users >>>> 3 we can make deprecation occur on N% of pageloads (with consistency >>>> over time), no sites get singled out, no users get singled out. >>>> >>>> If there is user-facing breakage, #1 puts some users into a group with >>>> breakage on all impacted sites, meanwhile the world carries on around them. >>>> >>>> If there is site-facing breakage (e.g. metrics problems, user sessions >>>> not being destroyed when they close the tab,...) #2 puts some sites 100% >>>> into that breakage immediately, causing a scramble. >>>> >>>> #1 and #3 mean that site-facing breakage will increase gradually, I >>>> think this is important. This was OK on well-resourced sites, most of whom >>>> talk directly to WEC. >>>> #2 and #3 mean that for any user, user-facing breakage will increase >>>> gradually. >>>> >>>> I expect user-facing breakage is going to be quite rare. I don't think >>>> we've seen any in the top-50. Also in discussions at TPAC, I heard of >>>> several site-facing problems but no user-facing problems. So perhaps we >>>> should not worry about users being in a group with breakage on ALL sites >>>> when in reality, that will be 0 or 1 site that any given user cares >>>> about. Another way to think of it is that #3 dsitributes the breakage >>>> across users+sites but users already distribute themselves somewhat >>>> randomly across sites, so this extra distribution is not buying us much. >>>> >>>> If it was going to be multiple sites for all users in the group then >>>> trying to spread the pain would make sense, however we probably shouldn't >>>> be doing this at all if the breakage lis that common. >>>> >>>> So maybe #1 is the way to go. It's certainly simpler >>>> >>>> F >>>> >>>>> >>>>> Thanks, >>>>> Rick >>>>> >>>>> On Sun, Jan 18, 2026 at 9:11 PM Fergal Daly <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi API owners, >>>>>> >>>>>> TL;DR I am asking for permission to start rolling out unload >>>>>> deprecation to the whole world, sticking to the schedule published >>>>>> here >>>>>> <https://developer.chrome.com/docs/web-platform/deprecating-unload> >>>>>> (1% in M145, 100% by M152). >>>>>> >>>>>> We have been at 100% of top-50 websites since M142. >>>>>> >>>>>> The general rollout will go from impacting 1% of pageloads to 100% of >>>>>> pageloads. Users will fall into one of 100 buckets. At each step, users >>>>>> in >>>>>> a single bucket will experience unload deprecation on N% of origins. As N >>>>>> increases, the set of sites will grow consistently (so if unload was >>>>>> deprecated on foo.com at N% for that bucket, it will also be >>>>>> deprecated at >N%). >>>>>> >>>>>> The impact of defaulting unload off for just the top-50 sites has >>>>>> been significant. At each step of the rollout we gained about half a >>>>>> percentage point of BFCache hit-rate. The experiment config is quite >>>>>> complex so we have not done a direct comparison of 0 vs all-50. I'd guess >>>>>> it's about a 3 percentage point improvement. I plan to do a direct >>>>>> measurement when we deprecate for all. >>>>>> >>>>>> We haven't received much feedback about the deprecation, although WEC >>>>>> folks have been working with sites to migrate away from unload. Others >>>>>> have >>>>>> decided not to do so and opted out of the deprecation. Things seem to be >>>>>> working as intended. >>>>>> >>>>>> Gilberto has examined the web archive to find which origins are >>>>>> explicitly disabling or re-enabling unload via Permissions-Policy. The >>>>>> raw >>>>>> data is here >>>>>> <https://docs.google.com/spreadsheets/d/1MhMH00SBB_Soz4ZY_L56WMtGIGfGjWaLhTonyDE47a8/edit?gid=1768778784#gid=1768778784> >>>>>> (google internal link), a summary of adoption by rank is below (based on >>>>>> 2025-12-01 snapshot). This shows that plenty of sites outside of the >>>>>> top-50 >>>>>> are aware of this and explicitly taking control. >>>>>> >>>>>> One interesting incident occurred recently, where a widely used 3rd >>>>>> party lib added an unload handler. This caused a global regression of >>>>>> bfcache hit-rate of 4 percentage points. Gilberto worked with them to >>>>>> remove their unload handler and the regression should now be resolved. >>>>>> This >>>>>> shows the importance of removing unload as a BFCache blocker and this >>>>>> deprecation is our way of doing that. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> F >>>>>> >>>>>> >>>>>> >>>>>> rank >>>>>> >>>>>> blocking_unload >>>>>> >>>>>> re_enabling_unload >>>>>> >>>>>> 1000 >>>>>> >>>>>> 28 >>>>>> >>>>>> 14 >>>>>> >>>>>> 5000 >>>>>> >>>>>> 27 >>>>>> >>>>>> 4 >>>>>> >>>>>> 10000 >>>>>> >>>>>> 51 >>>>>> >>>>>> 16 >>>>>> >>>>>> 50000 >>>>>> >>>>>> 147 >>>>>> >>>>>> 23 >>>>>> >>>>>> 100000 >>>>>> >>>>>> 137 >>>>>> >>>>>> 37 >>>>>> >>>>>> 500000 >>>>>> >>>>>> 407 >>>>>> >>>>>> 191 >>>>>> >>>>>> 1000000 >>>>>> >>>>>> 199 >>>>>> >>>>>> 128 >>>>>> >>>>>> 5000000 >>>>>> >>>>>> 925 >>>>>> >>>>>> 689 >>>>>> >>>>>> 10000000 >>>>>> >>>>>> 871 >>>>>> >>>>>> 695 >>>>>> >>>>>> 50000000 >>>>>> >>>>>> 917 >>>>>> >>>>>> 842 >>>>>> >>>>>> Total >>>>>> >>>>>> 3709 >>>>>> >>>>>> 2639 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, 19 Nov 2025 at 11:49, Fergal Daly <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Final progress update for this year. >>>>>>> >>>>>>> unload is now disabled by default for 100% of top-50 sites in M142 >>>>>>> and beyond. >>>>>>> >>>>>>> Next steps are to get approval from blink owners to start rolling >>>>>>> out to the whole world. Our published schedule calls for that to happen >>>>>>> starting with M145. I will wait to see if there is any negative feedback >>>>>>> before asking for that approval, >>>>>>> >>>>>>> F >>>>>>> >>>>>>> On Monday, October 27, 2025 at 5:55:39 PM UTC+9 Fergal Daly wrote: >>>>>>> >>>>>>>> Another progress update (sorry I missed the last one). >>>>>>>> >>>>>>>> >>>>>>>> - 100% ignored for the top-25 sites on our list from M141 >>>>>>>> ownards >>>>>>>> - at 50% ignored on the top 50 sites for M142 stable as it >>>>>>>> rolls out. This will go to 100% in a couple of weeks. >>>>>>>> >>>>>>>> We will let it cook over year end. >>>>>>>> >>>>>>>> So far nobody has raised any issues to us. I am aware of 1 site >>>>>>>> that is using the permissions policy to re-enable unload. We're going >>>>>>>> to do >>>>>>>> a more thorough survey with HTTP archive to see if others are doing >>>>>>>> this. >>>>>>>> There has been a nice bump in BFCache-hitrate though, so many sites >>>>>>>> are not. >>>>>>>> >>>>>>>> Hopefully in the new year, I will seek permission to start the >>>>>>>> general rollout, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Tuesday, August 26, 2025 at 10:28:19 AM UTC+9 Fergal Daly wrote: >>>>>>>> >>>>>>>> Another progress update >>>>>>>> >>>>>>>> - 100% ignored for the top-5 sites on our list from M139 ownards >>>>>>>> - 10% ignored for the top-10 sites on our list for M140 (which >>>>>>>> will begin rollout in a day or two) >>>>>>>> >>>>>>>> >>>>>>>> - at 50% ignored on the top 25 sites for M141 non-stable >>>>>>>> >>>>>>>> >>>>>>>> - at 50% ignored on the top 50 sites for M142 non-stable (there >>>>>>>> are no M142 clients in existence, they will start once we branch >>>>>>>> M141 >>>>>>>> >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Thursday, July 31, 2025 at 1:45:32 PM UTC+9 Fergal Daly wrote: >>>>>>>> >>>>>>>> An update on the state of unload deprecation. We did not manage to >>>>>>>> stick to the schedule for a variety of reasons, however barring further >>>>>>>> unexpected problems, I expect to stick to it going forward. >>>>>>>> >>>>>>>> The current state is that unload handlers are >>>>>>>> >>>>>>>> - 100% ignored on www.google.com (the top-1 site in the list) >>>>>>>> for M135-M138 stable >>>>>>>> - 10% ignored on the top 5 sites for M139 stable which has just >>>>>>>> begun rollout <https://chromiumdash.appspot.com/schedule> and >>>>>>>> this will advance to 50% then 100% >>>>>>>> - at 50% ignored on the top 10 sites for M140 non-stable >>>>>>>> - at 50% ignored on the top 25 sites for M141 non-stable (there >>>>>>>> are no M141 clients in existence, they will start once we branch >>>>>>>> M140) >>>>>>>> >>>>>>>> The schedule is published here >>>>>>>> <https://developer.chrome.com/docs/web-platform/deprecating-unload> >>>>>>>> , >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> On Friday, February 21, 2025 at 3:01:48 PM UTC+9 Fergal Daly wrote: >>>>>>>> >>>>>>>> FYI, this is now at 50/50 in canary/dev for M134. I will advance it >>>>>>>> to beta in M134 but I won't go to stable in M134 since the plan is to >>>>>>>> enable each stage for a full development cycle and M134 is almost at >>>>>>>> the >>>>>>>> end of beta, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Friday, February 14, 2025 at 4:34:41 PM UTC+9 Fergal Daly wrote: >>>>>>>> >>>>>>>> On Thu, 13 Feb 2025 at 01:02, Rick Byers <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 5, 2025 at 3:56 AM Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Sat, 15 Jun 2024 at 00:19, Ian Clelland <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 14, 2024 at 11:08 AM Rick Byers <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Disabling unload by default with a deprecation trial and permission >>>>>>>> policy control to opt-back-in on the top 50 sites sounds good to me as >>>>>>>> the >>>>>>>> next step in the experiment. Even at 100%, I consider this a small >>>>>>>> fractional experiment due to applying only to the top 50 sites (even if >>>>>>>> that's more than 1% usage - from a developers impacted perspective it's >>>>>>>> tiny). Obviously we'll still have to be prepared to flip this off in >>>>>>>> the >>>>>>>> case of significant breakage reports. So LGTM. >>>>>>>> >>>>>>>> Personally I think ramping up the top-N site value is a better >>>>>>>> roll-out strategy for this feature than using fractional user >>>>>>>> deployment as >>>>>>>> it reduces the risk of confusing developers with hard-to-reproduce >>>>>>>> breakage. >>>>>>>> >>>>>>>> Thanks for all your diligence and effort here! >>>>>>>> Rick >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 14, 2024 at 1:24 AM Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> TL;DR: >>>>>>>> - no feedback from running at 1% on top-50 sites >>>>>>>> - asking for agreement on some further changes to handle some edge >>>>>>>> cases >>>>>>>> - asking for LGTM to roll out beyond 1% of top-50 sites >>>>>>>> >>>>>>>> From 2024-04-02 until 2024-05-20 we were at 1% of the top 50 sites >>>>>>>> having unload disabled by default. We received no feedback. >>>>>>>> >>>>>>>> During this time I figured out some exception cases that were >>>>>>>> missing from the original proposal. They are documented here >>>>>>>> <https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#proposed-solution> >>>>>>>> TL;DR >>>>>>>> - frameset frames, <embed> and <object> will inherit their parent's >>>>>>>> unload policy directly as they have no `allow` attribute. >>>>>>>> - documents without headers (e.g. "about:blank", "data:...") will >>>>>>>> behave as if they had their parent's header (the `allow` attribute will >>>>>>>> still be a factor) >>>>>>>> >>>>>>>> These are not specific to unload. Both of these seem like necessary >>>>>>>> exceptions for any attempt to deprecate a feature by using a >>>>>>>> default-none >>>>>>>> Permissions-Policy. >>>>>>>> >>>>>>>> >>>>>>>> We've generally worked with this model in Permissions-Policy up >>>>>>>> until now, and it would be good to formalize it somewhere. I think >>>>>>>> that the >>>>>>>> other critical attribute of these "headerless" documents is that the >>>>>>>> embedding document is essentially in control of the document content as >>>>>>>> well. This is true for about:blank, data: urls, and <iframe srcdoc> >>>>>>>> cases, for instance, but might not be true for non-HTTP schemes like >>>>>>>> file:. >>>>>>>> >>>>>>>> <frame>, <object> and <embed> are deprecated in the the HTML spec, >>>>>>>> and while I don't think that we want to start adding attributes to >>>>>>>> those >>>>>>>> (although we had tossed the idea around several years ago), it's still >>>>>>>> important to ensure that they continue to work sensibly. Carving out a >>>>>>>> special case here for unload makes sense; thanks for considering that >>>>>>>> and >>>>>>>> thinking it through, Fergal. >>>>>>>> >>>>>>>> >>>>>>>> These issues are now fixed (https://crbug.com/40285153). >>>>>>>> >>>>>>>> Rick, I think the idea of incrementally rolling out to top-N sites >>>>>>>> is an interesting one. I have written up a doc >>>>>>>> <https://docs.google.com/document/d/1JBTKMea-qvj1La1904wqZ3gZU_E7lGzcZrwSn2YSQtI/edit?tab=t.0> >>>>>>>> describing the full rollout. TL;DR, www.google.com is #1 and so we >>>>>>>> would end up deprecating unload for 90% of users on www.google.com >>>>>>>> within 2 weeks of stable being released. On the next milestone another >>>>>>>> 4 >>>>>>>> origins would experience the same thing. The original proposal was that >>>>>>>> each origin would gradually approach 90% deprecation, with no origin >>>>>>>> being >>>>>>>> "first". Do you think it's better to have the suddenly fully deprecated >>>>>>>> (dev/canary/beta would still give warning) or the more complex and >>>>>>>> maybe >>>>>>>> less debuggable but less sudden version? >>>>>>>> >>>>>>>> >>>>>>>> It's really hard to say, this is new territory for us. I worry >>>>>>>> about adding too much complexity here - we want something developers >>>>>>>> can >>>>>>>> reason about. But in general I'm happy to defer to your judgement and >>>>>>>> in >>>>>>>> general encourage you to avoid the trap of being over-cautious here. We >>>>>>>> have this all under finch control and have developer opt-out >>>>>>>> available, so >>>>>>>> in general it seems OK to me to take some risk as long as we are highly >>>>>>>> responsive to reports of issues. >>>>>>>> >>>>>>>> >>>>>>>> Fair enough. I will proceed with caution. Could you LGTM the extension >>>>>>>> on the deprecation trial >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/cIQexpV5M08>? >>>>>>>> Thanks, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ian >>>>>>>> >>>>>>>> >>>>>>>> I have prepared a patch >>>>>>>> <https://github.com/fergald/webappsec-permissions-policy/compare/add-none...fergald:webappsec-permissions-policy:add-none-headerless> >>>>>>>> against >>>>>>>> the original PR >>>>>>>> <https://github.com/w3c/webappsec-permissions-policy/pull/515> on >>>>>>>> the PP-spec. It still needs some work to be precise about >>>>>>>> "headerless". I >>>>>>>> will prepare a PR for the frames without `allow`, that might be in the >>>>>>>> PP >>>>>>>> spec or it might be in the HTML spec. >>>>>>>> >>>>>>>> Once the above are implemented, I would like to gradually ramp up >>>>>>>> to 100% of top-50 sites. Are there concerns? Can I get LGTMs? >>>>>>>> >>>>>>>> An alternative would be to start a ramp-up across all sites. I'm >>>>>>>> suggesting sticking with the top-50 for now since they will tend to >>>>>>>> have >>>>>>>> better monitoring and better ability to give timely feedback if there >>>>>>>> are >>>>>>>> problems. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Tue, 6 Feb 2024 at 03:38, Mike Taylor <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> No concerns, thanks for the update Fergal. >>>>>>>> On 2/5/24 5:05 AM, Fergal Daly wrote: >>>>>>>> >>>>>>>> FYI, due to various complications we are just starting the initial >>>>>>>> deprecation of unload in M122. This means that on M122 up to 1% of >>>>>>>> users >>>>>>>> can experience unload deprecation on the top 50 websites >>>>>>>> <https://en.wikipedia.org/w/index.php?title=List_of_most-visited_websites&oldid=1198053805> >>>>>>>> . >>>>>>>> >>>>>>>> I would like to revise DeprecateUnloadOptOut to run from 122 for 12 >>>>>>>> milestones, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Thu, 19 Oct 2023 at 06:28, Chris Harrelson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> LGTM3 to start the deprecation trial as proposed in M119. >>>>>>>> >>>>>>>> On Thu, Sep 28, 2023 at 10:00 PM Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> One more thing. Can I get an explicit LGTM for a deprecation trial >>>>>>>> starting in M119. It would be named DeprecateUnloadOptOut and I'm >>>>>>>> initially >>>>>>>> requesting it to run for 12 milestones although I expect it will >>>>>>>> actually >>>>>>>> run for more. >>>>>>>> >>>>>>>> Happy to send an explicit "Request for Deprecation Trial" on this >>>>>>>> if needed, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Tuesday, September 19, 2023 at 9:24:36 PM UTC+9 Fergal Daly >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Sat, 16 Sept 2023 at 23:40, Yoav Weiss <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> LGTM2 (although I'm not sure it's needed - are we considering this >>>>>>>> an experiment?) >>>>>>>> >>>>>>>> >>>>>>>> I guess, since it's less than 1%, you're right, this doesn't need >>>>>>>> it but I appreciate the feedback and the blessing, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 11, 2023 at 12:37 PM Mike Taylor < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> LGTM1 to deprecate at 1% for M118+. Please return and report on >>>>>>>> your findings - whether that was "we had to turn it off because >>>>>>>> $REASON", >>>>>>>> or "we would like to go to N% based on $REASON". In my experience, it's >>>>>>>> hard for sites to observe the effects of a 1% experiment, but we have >>>>>>>> to >>>>>>>> start somewhere. :) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Mike >>>>>>>> On 9/11/23 2:55 AM, Fergal Daly wrote: >>>>>>>> >>>>>>>> On Fri, 8 Sept 2023 at 23:19, Mike Taylor <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Fergal, >>>>>>>> >>>>>>>> Just to clarify - are you only requesting to deprecate at 1% for >>>>>>>> M118 (and presumably report back on findings), or for M118+ and then >>>>>>>> eventually request to go higher? >>>>>>>> >>>>>>>> WeI would like M118+. It might take a little while for a reaction. >>>>>>>> I would not want the effect to disappear after 4 weeks and we miss >>>>>>>> feedback >>>>>>>> as a result. If you don't want it to be indefinite, I would say 3 >>>>>>>> versions >>>>>>>> would be enough. I would like this to be allowed but not required. We >>>>>>>> may >>>>>>>> propose to accelerate *before* 3 versions have passed, depending on >>>>>>>> results, enterprise, etc >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Mike >>>>>>>> On 9/8/23 6:24 AM, 'Fergal Daly' via blink-dev wrote: >>>>>>>> >>>>>>>> Hi Blink API owners, >>>>>>>> >>>>>>>> We would like to get approval to start doing a limited experiment >>>>>>>> on deprecating unload handlers, proposal below. First some updates. >>>>>>>> >>>>>>>> MessagePorts >>>>>>>> >>>>>>>> After some investigation, it turns out that Robert Knight >>>>>>>> (Hypothesis)'s use of `unload` to signal that a MessagePort can be >>>>>>>> closed >>>>>>>> can be replaced with `pagehide` since the navigation in question are >>>>>>>> always >>>>>>>> in subframes. More generally, signalling like this is not a reliable >>>>>>>> way to >>>>>>>> handle this. Use of WeakRefs or combining with WeakRefs will capture >>>>>>>> all >>>>>>>> occurrences. The full details are in this explainer >>>>>>>> <https://github.com/fergald/explainer-messageport-close> which >>>>>>>> proposes to add an explicit event for this. Firefox have already >>>>>>>> said >>>>>>>> <https://github.com/whatwg/html/issues/1766#issuecomment-1708027883> >>>>>>>> they would implement it. Implementing it isn't a blocker for unload, >>>>>>>> the >>>>>>>> explainer documents how to do it with WeakRefs, however it is a >>>>>>>> nice-to-have. >>>>>>>> >>>>>>>> Other use cases >>>>>>>> >>>>>>>> Nobody else has raised any problematic use cases. >>>>>>>> >>>>>>>> Enterprise >>>>>>>> >>>>>>>> We are discussing with enterprise software vendors, how to make the >>>>>>>> deprecation easier for them, in particular for their on-premises >>>>>>>> customers. >>>>>>>> >>>>>>>> We have added an enterprise policy that allows enterprises to >>>>>>>> disable the deprecation (leave the default as enabled) for their >>>>>>>> managed >>>>>>>> devices. There is also a chrome://flags/deprecated flag for BYOD. >>>>>>>> >>>>>>>> We are considering a 3rd-party deprecation-trial. That would likely >>>>>>>> be ready in M119 (there are some implementation issues that make it >>>>>>>> non-trivial). >>>>>>>> >>>>>>>> The discussions are ongoing. >>>>>>>> >>>>>>>> Proposal >>>>>>>> >>>>>>>> We would like to go ahead in M118 with the following - deprecate >>>>>>>> unload (by changing the permissions policy default) for 1% of users on >>>>>>>> a >>>>>>>> limited allowlist of hosts. This would be for a limited set of hosts >>>>>>>> (top N >>>>>>>> hosts by traffic in UKM for a value of N that may increase as we gather >>>>>>>> data). This will avoid enterprise vendor instances while still >>>>>>>> allowing us >>>>>>>> to get started with the deprecation, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Thu, 10 Aug 2023 at 20:33, Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Wed, 9 Aug 2023 at 07:23, Brandon Heenan <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Still, previous breaking changes to the unload event that affected >>>>>>>> SAP were present in the /deprecated page, so the safest thing to do is >>>>>>>> to >>>>>>>> follow the same pattern here, no? >>>>>>>> >>>>>>>> >>>>>>>> The switch landed here <https://crrev.com/c/4736842>, It's in >>>>>>>> M117. I've sent a CL <https://crrev.com/c/4764528> to make it >>>>>>>> appear on the deprecated flags page. We can CP that, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> It's not marked as a deprecated feature, so it's just in the >>>>>>>> regular flags UI. We can CP a tiny change to move it. What gives me >>>>>>>> pause >>>>>>>> is that the page says >>>>>>>> >>>>>>>> "These features are disabled by default. They will not be available >>>>>>>> in future versions of Chrome." >>>>>>>> >>>>>>>> This doesn't quite match what we are doing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Tue, 8 Aug 2023 at 08:00, Brandon Heenan <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Flipping the permission policy default is still a breaking change >>>>>>>> that requires some action from the developer to keep unload events, >>>>>>>> right? >>>>>>>> If so, we still want en entry in the /deprecated page so that unmanaged >>>>>>>> (vendors/BYOD/outbound) users accessing on-prem deployments have some >>>>>>>> mitigation. Kenji and I discussed this case with SAP last week, and >>>>>>>> that >>>>>>>> level of mitigation seemed necessary. >>>>>>>> >>>>>>>> >>>>>>>> It's just about naming/presentation - I'm adding a switch no matter >>>>>>>> what, just whether it shows in the deprecated tab or the main tab, >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan <[email protected]> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> I looked into this, I'm not sure this should be a deprecated flag. >>>>>>>> It doesn't really fit the description. Some time in the future when we >>>>>>>> start to fully disable unload, there should be a deprecated flag for >>>>>>>> unload >>>>>>>> but right now we are just flipping the permission policy default. >>>>>>>> >>>>>>>> Are you OK with just adding a UI entry for the existing flag that >>>>>>>> controls this Permission-Policy rollout (which is named >>>>>>>> DeprecateUnload but >>>>>>>> I'm happy to rename it) >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_a-5pVrGgtK%3DckGMpTy%2BiyB%2BgG68E0AdUevr7OGJCF1A%40mail.gmail.com.
