reached out to folks representing 99% of the remaining Shared Storage API calls, and will reach out to the rest soon. We're confident that we can remove this API by the proposed milestone

quite easy to add, and just doing it could be easier than pondering the compat risk. However, we have to keep the policy for some number of milestones so it would delay the deletion of the

LGTM3 to deprecate. On 11/13/25 1:44 am, Daniel Bratell wrote: > > LGTM2 for deprecation (not for the actual removal) > > /Daniel > > On 2025-11-12 17:28, Vladimir

Protected Audience Intent to Deprecate > and Remove > , > Protected Audience features that were never launched beyond 20% Stable > will be ramped down by the end of 2025

> LGTM1 to deprecate. The plan to keep deprecation for 6 milestones > also sounds good. Please come back to this thread at a time when > you think the removal can proceed. Since

> > Intent to Deprecate and Remove: Protected Audience > > > Contact emails > > pauljensen@chromium.org > > > Explainer > > https://github

LGTM3 according to Vlad's plan. /Daniel On 2025-11-12 17:19, Chris Harrelson wrote: > LGTM2 with the same conditions Vlad mentioned. > > On Wed, Nov 12, 2025 at 8:16 AM

fallback seems to be acceptable /Daniel On 2025-11-10 01:45, Mike Taylor wrote: > > Ignoring rSAFor (which is handled in a different intent), from what I > can tell deprecating

being expected to implement > it and potentially break the standards compliance of their XML documents? > Surely the browser could be made to dispatch this polyfill whenever

ll have to work through them as part of the deprecation. It should be possible to look at data for both of these cases, although to Rick's point it may only be possible once we'

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

an app to load >> arbitrary Web content in a WebView, which in turn might include ads, or ask >> the user to sign in, make a payment, and so on. >> >> Thanks, >

you planning to ship? >> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | >> 816-678-7195 <(816)%20678-7195> >> *If an API's not

> "Deprecate" means that the feature still works but using it shows a > deprecation warning in the DevTools console and kicks Reporting API. > > IMO, we should

> approval to remove.) >> > > Will do. And yeah I didn't think I needed LGTMs to deprecate, only to > remove, right? Akin to I2P not needing LGTM, but I2S needing

from M128 to M130. On Friday, February 28, 2025 at 8:05:49 PM UTC Mike Taylor wrote: > Just for the history books: how long was CHIPS disabled in WebView? 127 to > 130? > On 2/26

we forgot to remove one property as >>> part of this deprecation and removal. We successfully removed >>> NavigateEvent's transitionWhile() (replaced

WebView team to proceed and will be > doing a gradual Finch rollout of the removal starting M133. Progress > will be tracked on this issue . > > Best, > Ayu > > On Monday

the "Intent to Deprecate" template from https://www.chromium.org/blink/launching-features/ without realizing it was not for "Intent to Deprecate and Remove

nobody seems to be calling them, it should be fine and 2 milestones should be enough to find deprecation warnings. LGTM3 On Thu, Nov 21, 2024 at 12:16 PM Mike Taylor wrote: > LGTM2 >

I struggle to see how removing a fallback will do anything to improve the user experience, and could prove to be a disaster for commercial products like ours. I hope some other solution

re going to clean up as soon as possible. Please disregard most sections of the email, the relevant bit is here: Reason this experiment is being extended We request to extend the origin

amend that to LGTM2 % filling out and request the Enterprise, > Debuggability, and Testing chips in chromestatus > > On 11/8/24 11:55 AM, Mike Taylor wrote: >> >

'll deprecate the method with `DeprecateAs` in the IDL file > 2. Then we'll add a blink runtime feature off by default that > hides the method with `RuntimeEnabled` to

> LGTM1 to remove - if there's no usage, now is the time to get that done. >>> >>> Relevant use counter for those interested: >>> https://chromestatus

> continue to support and invest in the Privacy Sandbox technologies. > While we can't predict what exact user preferences will be, it's > important for businesses

Good to know. Thanks folks. On Fri, Aug 9, 2024 at 12:04 PM Mike Taylor wrote: > +1 - no approvals needed. :) > On 8/9/24 1:20 AM, Domenic Denicola wrote: > > If this method was

> LGTM1 to add `position-area`, since it is an alias for `inset-area` that >> is shipped and is being deprecated. >> >> On Thu, Jul 11, 2024 at 12:22 PM Mason Freed

idea is to add `position-area` in M129, and deprecate (but not yet >>> remove) `inset-area` also in M129. And then ideally remove `inset-area` in >>> M131. Two

complete, to avoid related noise. On Wednesday, April 3, 2024 at 12:52:23 PM UTC+1 Noam Rosenthal wrote: > On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal > wrote: > >>