Re: [blink-dev] Change to storage pressure handling -- need launch review?

This indeed doesn't sound like a web-exposed change. It could potentially be observable in theory (e.g. by developers deliberately creating storage pressure and seeing eviction happening at different points in time than before), but it seems unlikely that this is something developers grew to rely o

Re: [blink-dev] Re: Intent to extend Origin Trial: Popover API

LGTM to extend experimentation to M112 On Mon, Dec 12, 2022 at 8:59 PM Mason Freed wrote: > > On Thu, Dec 8, 2022 at 11:26 PM Alex Russell > wrote: > >> Has this feature changed in a breaking way since the first OT? > > > Yes, in the course of the OT, the name of the attribute(s) changed from >

Re: [blink-dev] Intent to Ship: FedCM on cross-origin iframes

LGTM1 On Mon, Dec 12, 2022 at 8:14 PM Nicolás Peña wrote: > I was not aware that Permissions-Policy enables having support for just JS > or just HTTP header support, but in our case we want to ship both, which is > the default. I have added a couple of examples at the bottom of that > explainer.

[blink-dev] Change to storage pressure handling -- need launch review?

Hi blink-dev, On the storage team we are considering modifying the process by which Chromium attempts to resolve storage pressure. The rather hand-wavey spec is here[1]. Our changes will not affect any existing IDL or change conformance to any spec we know of. Our changes may be one or more of the

[blink-dev] Re: Intent to extend Origin Trial: Popover API

On Thu, Dec 8, 2022 at 11:26 PM Alex Russell wrote: > Has this feature changed in a breaking way since the first OT? Yes, in the course of the OT, the name of the attribute(s) changed from `popup` to `popover`. (Context here .) Some smaller details

Re: [blink-dev] Intent to Ship: Network State Partitioning

LGTM3. Thanks for your close collaboration with the security team here; I think the compromise you landed on is both reasonable and good. -mike On Mon, Dec 12, 2022 at 8:13 PM Chris Harrelson wrote: > LGTM2 > > On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss wrote: > >> LGTM1 >> >> Thanks for work

Re: [blink-dev] Intent to Ship: FedCM on cross-origin iframes

I was not aware that Permissions-Policy enables having support for just JS or just HTTP header support, but in our case we want to ship both, which is the default. I have added a couple of examples at the bottom of that explainer. On Monday, December 12, 2022 at 4:41:49 AM UTC-5 Yoav Weiss wro

Re: [blink-dev] Intent to Ship: Network State Partitioning

LGTM2 On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss wrote: > LGTM1 > > Thanks for working on this compromise between our security/privacy needs > and our performance goals!! > > On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >>

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: PointerEvent.deviceId for Mult-Pen Inking

--- *Sahir & Ben: wondering why a new deviceId field seems more logical now against the original proposal of repurposing the pointerId field? Is it because of the compat concern you raised in w3c/pointerevents/issues/353

Re: [blink-dev] Re: Abseil now allowed in Chromium code

You should start a new thread for this kind of question, rather than replying to this one. Additionally, if you're modifying Abseil, I don't think this question has anything to do with Chromium. You could try asking on an Abseil discussion group, but I suspect you're on your own, since you're modi

Re: [blink-dev] Re: Abseil now allowed in Chromium code

Hi, I want to use randen_engine, so I add code in \third_party\abseil-cpp\absl\random\random.h // Make randen_engine available for direct usage, because // absl::BitGen/InsecureBitGen uses always-on process-bound salt for seeded // generators. template using randen_engine = random_internal::ran

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: PointerEvent.deviceId for Mult-Pen Inking

Supporting consistent IDs for supported pens sounds great. Sahir & Ben: wondering why a new deviceId field seems more logical now against the original proposal of repurposing the pointerId field? Is it because of the compat concern you raised in w3c/pointerevents/issues/353

[blink-dev] Re: Intent to Ship: Deprecate Event.path

j jhuhsyhbhwbhb -- 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.

Re: [blink-dev] Intent to Ship: FedCM on cross-origin iframes

On Thu, Dec 8, 2022 at 4:38 PM Nicolás Peña wrote: > Contact emails > > n...@chromium.org > Explainer > > https://github.com/fedidcg/FedCM/blob/main/explorations/iframe_support.md > Would be great to have some more explicit examples in the explainer. For example, it's not immediately obvious to

Re: [blink-dev] Intent to Experiment: No-Vary-Search support in navigation prefetch cache

LGTM to experiment M110 till M115. On Thu, Dec 8, 2022 at 11:20 PM Liviu Tinta wrote: > Contact emails > > dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org > > Explainer > > https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md > > Specification > > https://wicg.