right place to ask but I'm curious what the status of this is? I'm on WebView 141 and it is still sending the X-Requested-With header. On Wednesday, April 19, 2023 at 2:55:38

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

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

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

been an intent to deprecate and > remove for this feature. However, that one failed to make it to the right > dashboards due to the subject line being incorrect. See that prior >

getting sites to update is a major >> hurdle. That said, after reading through the comments and linked issues on >> upstream repos (react-quill, etc) - nobody seems to

To be clear, this thread is about *deprecating the header*, not about adding the header or changing its behaviour. Thanks, Peter On Fri, Apr 12, 2024 at 4:06 PM Jeeva Kumar wrote: >

(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

usage seems to be dropping fairly rapidly, which is good. I've also been able to turn off mutation events for all of Google's internal web tests, and experienced very few failures

too obfuscated to be conclusive. >>> >>> Regards, >>> Brad >>> >>> On Tue, Feb 20, 2024 at 11:01 PM Yoav Weiss (@Shopify) < >

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

> >> We're currently debating if >> that is the right thing to do, or it'd be better if XHRs/fetch() required >> an explicit value. >> > >