steps 2 and 3. /Daniel On 2026-06-25 19:05, Chris Harrelson wrote: > LGTM2 > > On Thu, Jun 25, 2026 at 9:56 AM Yoav Weiss (@Shopify) > wrote: > > LGTM1 > > On Fri

steps 2 and 3. /Daniel On 2026-06-26 10:21, Yoav Weiss (@Shopify) wrote: > LGTM2 > > On Thu, Jun 25, 2026 at 11:12 PM Chris Harrelson > wrote: > > LGTM1 > > On Thu

a plan to remove >> it in Chrome-150. For example, currently the usage of >> sharedStorage.worklet.addModue() is at 3.1% of page loads. >> >> We >>

a plan to remove it >> in M150. Currently the usage is still 2.4% of page loads. >> >> We >> are proposing the following as next steps for removal and associated

a plan to remove it in >> Chrome-150. Currently the usage is 4.9% of page loads. >> >> We >> are proposing the following as next steps for removal and associated

, wanted to share a brief update on our progress here. As noted in my original email, our target to remove Related Website Sets and requestStorageAccessFor was M150; but given that usage

are about to become 2 weeks each so I think 6 is actually not > excessive, while 3 is too tight. > > LGTM2 > > /Daniel > On 2026-05-13 09:30, Nidhi Jaju wrote: > >

requiring me to modify a shell command every time I wanted to access one. On Tuesday, 5 June 2018 at 09:35:55 UTC+1 Philip Jägenstedt wrote: > Hi Jens, > > We understand that

no objections to the discussion points. I'll proceed as you > suggested. > Thanks! > > > - Yeonghan > > 2026년 3월 5일 목요일 AM 1시 28분 11초 UTC+9에 Philip Jägenstedt

Finch) to find real >> breakages that we may be missing. Further, disabling in >> Beta and Dev shortly after to get more data is also good. >> >> LGTM1 for the

now continuing to removal in M145, I landed a removal change before the branch point for M145 . On Fri, Nov 21, 2025 at 2:14 PM Mike Taylor wrote: > This makes a lot of sense, thanks. >

adding it to release notes. LGTM3 On Mon, Dec 15, 2025 at 9:41 AM Mike Taylor wrote: > Can you also request the Enterprise bit? I think they would probably want > this to appear in

Just wanted to ack the concerns again and will try to report back on any bumps along the way. On Sun, Nov 23, 2025 at 4:50 PM Rick Byers wrote: > LGTM3 to deprecate. > Yes I'm quite

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

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 >

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

>> and Testing in the chromestatus entry? Thanks! >>> >> On 8/26/24 12:40 PM, Mike Taylor wrote: >>> >> LGTM1 to remove - if there's no usage

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

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: > >>

We propose to block access to IP address 0.0.0.0 in advance of PNA >> completely rolling out. Chrome is deprecating direct access to private >> network endpoints from

too hard to catch the cause for the behavior change in the few sites that will be affected. Sounds good, I will keep the existing console message in there, at least for a while. On Wed, May

(resending to list) > > LGTM2 to go directly to removal (with a flag of course). Also, keep an eye > on enterprise feedback since they are a blind area. > > I took a look at

m glad to hear that's the feedback you get. In addition to actually minimizing harm, it's also an important goal of our process to earn and retain the trust of web businesses

as value and could not find it, I guess it is >>> not standardized yet. >>> >>> >> The `as` values are defined as a Fetch destination >> . For