Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

LGTM3 On Friday, May 3, 2024 at 1:34:21 PM UTC-4 Chris Harrelson wrote: > Thanks for these mini-explainers, they clarified what is changing for me! > > LGTM2 > > On Fri, May 3, 2024 at 9:31 AM 'Akash Nadan' via blink-dev < > blin...@chromium.org> wrote: > >> Hi Alex, >> >> Thanks for the

Re: [blink-dev] Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

fix, but since developers testing 3PCD > have been living in this world for a while and Firefox also has the > behavior, it seemed better to go the long route. > > ~ Ari Chivukula (Their/There/They're) > > > On Tue, Apr 30, 2024 at 11:34 AM Rick Byers wrote: > >> See

Re: [blink-dev] Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

Seems maybe like we introduced a bug in regressing from expected behavior and this could arguably be handled as a bug-fix? Regardless LGTM1 On Tue, Apr 30, 2024 at 11:32 AM Mike Taylor wrote: > On 4/30/24 7:15 AM, Ari Chivukula wrote: > > Contact emails > > aric...@chromium.org,

Re: [blink-dev] Intent to Ship: CSS Anchor Positioning

LGTM3 There's definitely some forward compat risk here, but we know adoption for these sorts of features tends to be slow before reaching all engines, so I'm confident in our ability to make small breaking changes as needed as the spec continues to mature. Seeing how much diligence and review has

Re: [blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

LGTM3 On Wed, Apr 3, 2024 at 11:30 AM Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote: > > LGTM1 > > The signals from other vendors and the CG discussion seem encouraging and > I agree that the future risk from an "all" value is probably outweighed

Re: [blink-dev] Intent to Prototype: Call stacks in crash reports from unresponsive web pages

`error.stack` getter), and there is already a lot >>>> of software, both client- and server-side, which deals with parsing the >>>> different browsers' formats. I don't think this would make the situation >>>> any worse. >>>> >>>> I d

Re: [blink-dev] Intent to implement and ship: WebAuthn WebDriver backup flags settings

Looks pretty straightforward to me and has some good support from other engines. LGTM1 /cc @Mathias Bynens in case he has any thoughts from a WebDriver perspective On Wed, Feb 14, 2024 at 6:21 PM Nina Satragno wrote: > Contact emails > > nsatra...@chromium.org, chrome-webau...@google.com > >

Re: [blink-dev] Re: Intent to experiment - WebAssembly JavaScript Promise Integration (update)

Sorry I missed this question! No, I did not notice that the entry was for 10 milestones. Our policy is a maximum of 6 milestones

Re: [blink-dev] Intent to Ship: Remove "window-placement" alias for permission and permission policy "window-management"

Presumably the risk of legitimate breakage here is bounded by the use of the Window Management API, right? Are there any UseCounters for the various Window Management operations? I couldn't find any at a quick glance. I imagine legitimate usage is dominated by a few sites with an obvious need (do

Re: [blink-dev] Intent to Prototype: Web Monetization

+1. I'm also supportive of prototyping this work. It's obviously a really tricky space, and it's not at all clear yet what would have to be true for us to ship a feature like this in Chrome. But supporting content creators is so important to Chromium's goals of a thriving web that I think we

Re: [blink-dev] Intent to Prototype: Call stacks in crash reports from unresponsive web pages

Not to distract from Dave's good technical questions. But I just wanted to say that I'm quite excited about this work - I think it's an important capability for any serious platform to have that app developers can get actionable crash and hang reports, and this has been a gap. Thank you for

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

Oof, I agree it's not good that the only documentation for the actual code point value is in Chromium code - that's the sort of thing our blink I2S process is supposed to prevent. In addition to confusion, there's also potential IP-risk downsides to this. Our blink process is generally to block

Re: [blink-dev] Intent to Ship: Protected Audience Ad slot size in real-time bidding signals fetch and update more interest group fields

ine it'll land shortly. > > On Wed, Jan 10, 2024 at 10:24 AM Rick Byers wrote: > >> Hi Paul, >> This looks like a minor addition to me. My only concern is that this >> spec PR <https://github.com/WICG/turtledove/pull/954> hasn't been >> reviewed yet, and

Re: [blink-dev] Re: Intent to experiment - WebAssembly JavaScript Promise Integration (update)

My only OT-blocking concern in the original thread was the "developers: no signals". But that was answered there . Yoav, I think your questions are not OT-blocking, right? LGTM to

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

This is a pretty niche and tiny addition which matters a lot to probably a couple websites in the world, and not at all to everyone else. It's a shame that it's taken over a year of discussion on what to ship. Worst case and we get this wrong and have something better in the future, I can't

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

It would be great to get an official response from WebKit and Mozilla to make sure we understand their position, but I don't think we should block further on it. I understand why they might have concerns given their engine's preference for embeds being anonymous. In Chromium we've been consistent

[blink-dev] New API owner: Domenic Denicola

Hi blink-dev, +Domenic Denicola has volunteered to donate his time and considerable web platform expertise to reviewing intent threads as an API owner. Domenic is very active in the web standards community including as an HTML editor, runs our spec mentors

Re: [blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

LGTM to extend. Breaking the transitive dependency problem with OOPIF seems like an effective and pragmatic strategy to me, I'm excited to see where that goes. One nit below. On Fri, Jan 19, 2024 at 12:06 PM Camille Lamy wrote: > Contact emails > > v...@chromium.org cl...@chromium.org > >

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

LGTM3 On Wed, Jan 3, 2024 at 6:44 PM Mike Taylor wrote: > No concerns. LGTM2 > On 1/3/24 1:41 PM, Chris Harrelson wrote: > > LGTM1 > > On Wed, Jan 3, 2024 at 5:05 AM Orr Bernstein wrote: > >> Hi all, >> >> Thank you for your guidance here. I've updated the chromestatus entry to >> reflect the

Re: [blink-dev] Re: Intent to Ship: Import attributes 'with' syntax

LGTM3 On Wed, Jan 10, 2024 at 11:57 AM Philip Jägenstedt wrote: > LGTM2 > > On Wed, Jan 10, 2024 at 5:16 PM Yoav Weiss wrote: > >> LGTM1 >> >> On Wed, Jan 10, 2024 at 5:08 PM Nicolò Ribaudo >> wrote: >> >>> > Like other JS language changes, I'm guessing we expect developers to >>> use UA

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

en though that means another clean-up CL later. On Wed, Jan 10, 2024 at 10:44 AM Daniel Bratell wrote: > LGTM1 - I agree that this is small enough to just proceed. > > /Daniel > On 2024-01-10 16:40, Noam Rosenthal wrote: > > > > On Wed, Jan 10, 2024 at 3:32 PM Rick Byers w

Re: [blink-dev] Intent to Ship: CSS Pseudo Element ::backdrop inheriting from Originating Element

Given how trivial and niche this is and that WebKit and Gecko have both shipped this without any apparent compat fallout, I agree the compat risk is very low. I'm ok treating it as a bugfix, but please circle back here (and consider using your killswitch) if you hear of any breakage in practice.

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

Hi Noam, This seems pretty trivial to me. The spec change is trivial and presumably any review feedback will only be editorial (not functional), so I'm OK not blocking approval on the spec PR landing. But could you get a WPTs implemented and at least ready to land (eg. along with the

Re: [blink-dev] Intent to Ship: Protected Audience Ad slot size in real-time bidding signals fetch and update more interest group fields

Hi Paul, This looks like a minor addition to me. My only concern is that this spec PR hasn't been reviewed yet, and we generally prefer for all tests to land before approval. Would it be reasonable to get those done before we approve this? Thanks,

Re: [blink-dev] Intent to experiment - Wasm JavaScript Promise Integration

Hi Francis, This seems good to experiment with to me. But the key question is who is actually going to test it out in production? You mention "no signals" for web developer interest. There's not much point in doing the overhead of an OT unless we have at least one developer who wants to test out

Re: [blink-dev] Intent to Ship: WebGPU: separate Read-only depth-stencil

Hi Corentin, This looks minor and probably pretty easy. But we do normally like to see spec PRs and tests land (or have a discussion around why they're blocked) before approving. Thoughts? Rick On Fri, Jan 5, 2024 at 8:18 AM Corentin Wallez wrote: > Contact emailscwal...@google.com > >

Re: [blink-dev] PSA: Browser text zoom on Android will now work like it does on desktop

Hi Jonathan, In doing bug triage, I'm randomly coming across multiple web developers confused by this behavior. Do we need a blog post perhaps to help raise awareness and

Re: [blink-dev] Re: Intent to Ship: WebGL drawingBufferStorage

On Fri, Dec 15, 2023 at 4:49 AM 'Christopher Cameron' via blink-dev < blink-dev@chromium.org> wrote: > Thank you! > > On Wed, Nov 29, 2023 at 4:24 PM Yoav Weiss wrote: > >> Thanks! This seems like an important problem to solve.. >> >> On Monday, November 27, 2023 at 10:20:37 PM UTC+1 Christopher

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

realize we were wrong and unship) is what we mean by the blink process being designed for "eventual interoperability". On Thu, Dec 14, 2023 at 4:34 AM Henrik Boström wrote: > Thanks, Rick. Responses inline. > > On Wednesday, December 13, 2023 at 6:39:48 PM UTC+1 Rick Byers

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

On Wed, Dec 13, 2023 at 12:39 PM Rick Byers wrote: > I looked into the details of the standards debate on this issue. It sounds > like it's still unclear whether the spec for this has WG support or not, > right? I certainly wouldn't want to mislead anyone as to API maturity /

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

I looked into the details of the standards debate on this issue. It sounds like it's still unclear whether the spec for this has WG support or not, right? I certainly wouldn't want to mislead anyone as to API maturity / likely interoperability by shipping based on a WebRTC WG specification if

Re: [blink-dev] Intent to Ship: CSSKeyframesRule.length

LGTM3 But note that our guidelines do require a flag , and I believe it should be absolutely trivial to do so with a RuntimeEnabledFeature (like maybe 30 characters of typing?). But

Re: [blink-dev] Intent to Ship: Storage Buckets API

LGTM2 +1 to raising the bar on test automation, but only in the cases where there aren't unreasonable burdens and there is clear significant test coverage value (i.e., not this specific case). Thanks for the analysis Evan and Philip! On Wed, Dec 13, 2023 at 8:10 AM Philip Jägenstedt wrote: >

Re: [blink-dev] Intent to Ship: Navigational prefetch: follow redirects

Personally I'd consider this prefetch behavior change to be more of a UA impl detail than a "web exposed API". I'm really glad you're covering this in a spec and WPT in the hopes of moving prefetch towards more interoperability long-term (as opposed to the historically very UA-heuristic-centric

Re: [blink-dev] Re: Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.

Thanks for the PSA Anupam. Since this is UA-defined behavior of the clipboard APIs and not likely to have a compat impact, I'm supportive of treating it as a PSA. Still, like most behavior-impacted bugfixes in blink, there might be some possible compat risk here. Is it relatively easy to make the

Re: [blink-dev] Intent to Extend Experiment: Compute Pressure API

; > > On Wednesday, December 6, 2023 at 6:57:09 PM UTC+2 Chris Harrelson wrote: > >> On Tue, Dec 5, 2023 at 11:20 AM Rick Byers wrote: >> >>> Hi, >>> Can you please request review for the security, privacy and >>> debuggability bits now in the chrom

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

eports of non-trivial stable breakage). On Wed, Dec 6, 2023 at 12:34 PM Robert Flack wrote: > >> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers wrote: >> >>> API owners met and discussed this one briefly today. There was agreement >>> that more work nee

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

100% but be prepared to killswitch if there are non-trivial reports of breakage, then revisit with either a migration plan (outreach, blog post) or proposed spec change WDYT? Rick On Tue, Dec 5, 2023 at 3:42 PM Rick Byers wrote: > Hey Mustaq, > Thanks for pushing to get this long-time int

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

Hey Mustaq, Thanks for pushing to get this long-time interop issue addressed! I assume cancelling the mousedown (but not the mousemove) still prevents selection and drag-and-drop in all browsers, is that right? That's the pattern I'd expect is most common. Also, what's the behavior of pointermove

Re: [blink-dev] Intent to Ship: Auto Sizes for Lazy Loaded Images with Srcset

Nice! LGTM1 On Fri, Dec 1, 2023 at 2:08 AM Traian Captan wrote: > Contact emailstcap...@chromium.org > > Explainerhttps://github.com/whatwg/html/issues/4654 > > Specificationhttps://html.spec.whatwg.org/#sizes-attributes > > Summary > > Auto Sizes allows developers to set the sizes attribute to

Re: [blink-dev] Intent to Ship: Attribution Reporting Features (Reduced Aggregate Delays, Event-Level Report Epsilon Field, Reserved Keys)

LGTM1 On the interoperability risks front I see there's still no official position on the API from Mozilla or WebKit . On Thu, Nov 30, 2023 at 3:38 PM 'Akash Nadan' via blink-dev

Re: [blink-dev] Intent to Extend Experiment: Compute Pressure API

Hi, Can you please request review for the security, privacy and debuggability bits now in the chromestatus tool? Perhaps there's some history somewhere you can point at from the first OT? Otherwise, seems reasonable to extend to me. Rick On Mon, Dec 4, 2023 at 1:59 PM Mandy, Arnaud wrote: >

Re: [blink-dev] Intent to Ship: Multiple Readers and Writers in File System Access API

LGTM2. Looks like the spec PR is reviewed but just blocked waiting for input from a 2nd implementor, but Firefox has implemented their support. Can you poke the relevant Firefox folks to see if someone can chime in on the spec PR to help get it landed? But doesn't seem necessary to block this I2S

Re: [blink-dev] Intent to Ship: Extension of WebDriver command for clicking on FedCM dialogs

LGTM2 On Tue, Dec 5, 2023 at 12:31 PM Mike Taylor wrote: > LGTM1 > On 12/5/23 3:44 AM, 'Zachary Tan' via blink-dev wrote: > > My mistake - it is indeed without the "k", thanks for double checking. > > On Tue, Dec 5, 2023 at 5:34 PM Domenic Denicola > wrote: > >> >> >> On Tue, Dec 5, 2023 at

[blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML format

By the way, for others trying to follow the history, the correct link to the original thread on this is https://groups.google.com/a/chromium.org/g/blink-dev/c/oiPCXHy9kRE/m/YS2sxbIQAAAJ On Tue, Dec 5, 2023 at 1:56 PM Rick Byers wrote: > Thanks for getting this cleaned up and clarif

[blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML format

Thanks for getting this cleaned up and clarified, and for getting the spec PR landed. This now seems quite trivial to me - just extending the existing unsanitized reading capability into an option of the async clipboard API. LGTM2 On Wed, Nov 29, 2023 at 4:39 PM Alex Russell wrote: > Thanks for

Re: [blink-dev] Intent to Ship: Third-party cookie deprecation exemption heuristics

LGTM2 Thank you for putting the extra rigor and effort into trying to specify and align on this behavior, rather than just copy the precedent set by the other two engines in relying on non-standards-track heuristics! It's exactly in these messy real-world examples of web behavior that our

Re: [blink-dev] Intent to Ship: Fenced Frames - Enable Leaving IGs, and Ads Report at Top Level Navigation Start (Chrome - 120)

LGTM1 On Fri, Dec 1, 2023 at 4:55 AM 'Liam Brady' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > shivani...@chromium.org, jkar...@chromium.org, lbr...@google.com, > xiaoche...@google.com > > Explainer(s) > > Enable Leaving Ad Interest Groups from Urn iFrames and Ad Component

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446 > > > On Thu, Nov 30, 2023 at 12:14 AM Rick Byers wrote: > >> Interesting. Could you try to improve the tests to capture the interop >> difference and ensure passing reflects

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

quot;0px" > } > ); > observer.observe(target); > }; > > function callback(entries) { > console.log(`isIntersecting = ${entries[0].isIntersecting}`); > } > > > > > > On Mon, Nov 27, 2023 at 11:40 PM Rick Byers wrote: > >> On Wed, Nov 22, 20

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: require user gesture for resize APIs

LGTM1 >>> >>> On Wednesday, November 29, 2023 at 4:04:49 PM UTC+1 Tommy Steimel wrote: >>> >>>> Okay the security reviewer has now re-reviewed it given the updated >>>> information. Thanks! >>>> >>>> On Mon, Nov 27, 202

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: require user gesture for resize APIs

On Wed, Nov 22, 2023 at 11:49 PM 'Tommy Steimel' via blink-dev < blink-dev@chromium.org> wrote: > > On Tue, Nov 21, 2023 at 9:43 PM Yoav Weiss wrote: > >> >> >> On Friday, November 17, 2023 at 8:47:34 PM UTC+1 Tommy Steimel wrote: >> >> Contact emailsstei...@chromium.org, liber...@chromium.org

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss wrote: > Thanks, that sounds like a strict improvement. > > On Wed, Nov 22, 2023 at 6:25 AM Traian Captan > wrote: > >> Yes, that's correct. >> >> >> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss >> wrote: >> >>> Do I understand correctly that currently

Re: [blink-dev] Intent to Extend Experiment: ServiceWorker static routing API

LGTM to extend to M124. I hope you are able to get good partner feedback and are ready to I2S then! Rick On Tue, Nov 28, 2023 at 3:20 PM Shunya Shishido wrote: > > *Contact emails* > > yyanagis...@google.com, sisidov...@chromium.org > > Explainer > >

Re: [blink-dev] Intent to Ship: View Transitions: transition types

LGTM3 On Thu, Nov 23, 2023 at 1:44 AM Mike Taylor wrote: > LGTM2 > On 11/22/23 11:15 AM, Yoav Weiss wrote: > > LGTM1 > > On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote: > > > > On Thu, Nov 9, 2023, 12:54 Mike Taylor wrote: > > On 11/8/23 3:53 PM, Vladimir Levin wrote: >

Re: [blink-dev] Intent to Ship: CSS font-palette property animation

LGTM3 On Sun, Nov 26, 2023 at 3:09 AM Mike Taylor wrote: > LGTM2 > On 11/23/23 8:39 AM, Yoav Weiss wrote: > > LGTM1 assuming there aren't any surprises on that front. Thanks!! > > On Thu, Nov 23, 2023 at 2:33 PM Dominik Röttsches > wrote: > >> Hi Yoav, >> >> On Wed, Nov 22, 2023 at 6:46 PM

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

All the other gates are now approved. I see there's a larger TAG review open which includes this feature, but it sounds like this generic (not codec-specific) feature is the direction TAG is encouraging. I don't think we need to block this

Re: [blink-dev] Intent to Ship: WebGPU default entry points to shader modules

Thanks, good enough for me! LGTM1 On Fri, Nov 24, 2023 at 8:32 AM François Beaufort wrote: > > > On Fri, Nov 24, 2023 at 1:46 AM Rick Byers wrote: > >> Seems trivial to me, just one little question: >> >> On Thu, Nov 23, 2023 at 10:34 AM 'François Beaufort

Re: [blink-dev] Intent to Ship: WebGPU default entry points to shader modules

Seems trivial to me, just one little question: On Thu, Nov 23, 2023 at 10:34 AM 'François Beaufort' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > fbeauf...@google.com, cwal...@google.com > > Explainer > > https://github.com/gpuweb/gpuweb/issues/4342 > > Specification > > >

Re: [blink-dev] Intent to Prototype: Allow for WebAuthn credential creation in a cross-origin iframe

Note FedCM, PaymentRequest and Storage access API effectively all follow this policy too. 3PCD doesn't block cross-origin information sharing, it just requires user consent (and hopefully understanding) for doing so. These patterns all seem strictly stronger in terms of transparency and control

Re: [blink-dev] Intent to Ship: EditContext API

; LGTM3 >> On 11/8/23 12:13 PM, Alex Russell wrote: >> >> +1 to the evidence from OT being persuasive. >> >> LGTM2 >> >> On Wednesday, November 8, 2023 at 8:56:24 AM UTC-8 Rick Byers wrote: >> >>> It certainly sounds to me that there's addition

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (further gating for trigger verbose debug reports)

LGTM3 On Wed, Nov 8, 2023 at 1:04 AM Yoav Weiss wrote: > LGTM2 > > On Tuesday, November 7, 2023 at 2:44:47 AM UTC+1 Mike Taylor wrote: > >> Thanks Akash. >> >> LGTM1 % sending out an email to the >> attribution-reporting-api-...@chromium.org group. >> On 11/6/23 4:52 PM, Akash Nadan wrote: >>

Re: [blink-dev] Intent to Ship: EditContext API

It certainly sounds to me that there's additional work to be done here, but I agree with Daniel that changing event order is not something we can do lightly. Gregg, could you please file an issue on the spec so the discussion can continue there? Given

Re: [blink-dev] Re: Intent to Prototype: Web environment integrity API

Thank you for the update and cleanup Ben. Also thank you very much for all your hard work trying to balance very difficult competing goals, engaging openly with constructive criticism and reevaluating the approach. Personally, I'm still optimistic that we (the open web community) will find ways

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

LGTM, no concerns from me with experimenting. It seems like user and enterprise controls are in place, and since this is just about proxying 3P resources that reduces the risk of it impacting either site functionality or network filtering policy. Note that Chrome already has another (fully

Re: [blink-dev] Intent to Ship: Ruby-specific display values

Hey Kent, To Fantasai's point, can you point to the specific WPT test cases for this intent? Are Chrome or Firefox failing any, and if so can you explain why? Tentative LGTM2 assuming WPT coverage shows we're matching Firefox behavior. Also happy to discuss the nuance here first if it's not

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

LGTM1 On Wed, Oct 25, 2023 at 4:33 PM 'Anupam Snigdha' via blink-dev < blink-dev@chromium.org> wrote: > I found a similar API canPlayType > > for > media element that informs the user about the supported MIME types.

Re: [blink-dev] Intent to Experiment: Extending Storage Access API (SAA) to non-cookie storage

This makes a lot of sense to me. I hate the idea of pushing folks to use cookies just due to SAA. I see the debate about wanting to deprecate the sync storage APIs, but I agree with you that this is not a useful lever in that debate. Instead we should come up with a holistic deprecation strategy.

Re: [blink-dev] Intent to Ship: Fenced Frame - Functionality Updates

LGTM3 On Fri, Oct 27, 2023 at 4:49 PM Chris Harrelson wrote: > LGTM2 > > On Thu, Oct 26, 2023 at 10:30 AM Mike Taylor > wrote: > >> Thanks for the design doc! The quote from kleber@ really helped me to >> understand the use case and developer need. It sounds like this is a small >> tweak to

Re: [blink-dev] Re: Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

only blocker was editorial review. This > appears to be a similar situation. > > On Fri, Oct 27, 2023 at 2:17 PM Rick Byers wrote: > >> FedCM has decided to follow a WHATWG-like working mode >> <https://github.com/fedidcg/FedCM/issues/431> where normative PRs land >>

Re: [blink-dev] Re: Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

FedCM has decided to follow a WHATWG-like working mode where normative PRs land only with 2+ implementer support. Given that reviews were requested almost 2 months ago, and the blink launch process is designed not to stall indefinitely on consensus, I

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

Exposing a new header and JS API temporarily for the purposes of an experiment (outside the context of an OT) is not something we've ever done before. But given the scope and requirements of this experiment and our desire to help enable the ecosystem to reason about it, it seems absolutely like

Re: [blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML

Hi Anupam, I've spent an hour or so trying to follow the history of this discussion, there's obviously been a lot of debate in this space over the years. I think your answer to Thomas's question is what really clarified this specific proposal to me - you're specifically interested in the case

Re: [blink-dev] Intent to Ship: MediaCapabilities: Query HDR support with decodingInfo()

Looks pretty straightforward to me, especially with Safari already shipping. LGTM1 On Wed, Oct 18, 2023 at 7:18 PM Dale Curtis wrote: > Contact emailsv...@microsoft.com, gw...@microsoft.com, > gur...@microsoft.com, dalecur...@chromium.org > > Explainer >

Re: [blink-dev] Intent to Ship: Permissions policy violation reports

Looks like a pretty straightforward combination of these established patterns, I like it! LGTM1 On Wed, Oct 25, 2023 at 8:42 AM Ian Clelland wrote: > > > On Wed, Oct 25, 2023 at 4:35 AM Yoav Weiss wrote: > >> >> >> On Tue, Oct 24, 2023 at 7:24 PM Ian Clelland >> wrote: >> >>> Contact

Re: [blink-dev] Intent to ship: The Login Status API and its use in FedCM

FWIW since the PR has landed, the correct link to reference the spec is https://fedidcg.github.io/FedCM/#browser-api-login-status. Since WebKit has expressed some interest in using this API in other scenarios than just FedCM I imagine there may be a request at some point to move it out of the

Re: [blink-dev] Intent to Ship: First-party sets

Thanks for the updates Chris! On Fri, Sep 29, 2023 at 12:36 PM Chris Fredrickson wrote: > Hi all, > > We've concluded our metrics analysis, and are rolling this feature out to > 100% of Chrome Stable clients. (We mitigated one regression in browser > startup time, and confirmed that all other

Re: [blink-dev] Intent to Ship: Attribution Reporting features (change registration limit, remove 1hr delay)

LGTM3 On Mon, Sep 18, 2023, 3:10 p.m. Mike Taylor wrote: > LGTM2 > On 9/16/23 10:28 AM, Yoav Weiss wrote: > > LGTM1 > > On Mon, Sep 11, 2023 at 10:58 PM 'Akash Nadan' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >> >> johni...@chromium.org, csharri...@chromium.org >> >>

Re: [blink-dev] PSA: WebHID in Extension Service Workers

Makes sense to me, thanks for the heads up! On Thu, Feb 16, 2023 at 11:29 PM 'Tarek ElBahnasawy' via blink-dev < blink-dev@chromium.org> wrote: > Contact emailsmattreyno...@chromium.org, chengw...@chromium.org > > Explainerwebhid/WEBHID_IN_EXTENSION_SERVICE_WORKERS_EXPLAINER.md at main >

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

LGTM3 On the compat front this is technically a breaking change for shipped APIs. Normally we'd want to see a more thorough a compat analysis to back up the claim of sites not being functionally broken. However, running through a compat analysis in my head I think

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

LGTM3 as not subject to blink process. But thanks for the heads up! On Wed, Sep 13, 2023, 5:50 p.m. Stephen Mcgruer wrote: > Thanks Mike! We were following through on the I2S process because we did > an I2E for this feature as a way to let folks verify that the UX change > wouldn't cause

Re: [blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

Sorry for the delay, LGTM2 I'm surprised you need a ramp-up for this. New APIs are generally safe so we usually don't finch them. But if you'd rather do a finch roll-out for extra safety, I have no objection. Rick On Thu, Aug 24, 2023 at 9:10 AM Peter Beverloo wrote: > Non-API OWNER LGTM to

Re: [blink-dev] Re: Intent to Deprecate: Remove "Sanitizer API MVP"

Note that our compat principles say "Generally we avoid breaking any use cases which cannot be shown to have a reasonable alternate implementation". While 0.00492% is tiny, it's still

Re: [blink-dev] Re: Intent to Prototype: Web environment integrity API

ection here will come from the respectful and thoughtful comments on this thread and elsewhere (including your blog <https://liberda.nl/weblog/trust-no-client/>, which I quite enjoyed), not the intimidation tactics occurring on the GitHub repo and elsewhere. Sorry for not being more c

Re: [blink-dev] Re: Intent to Prototype: Web environment integrity API

As one of the API owners and chromium community leaders, I'd just like to chime in on this personally with a meta-point: Thank you all for the thoughtful and constructive debate in this forum. As I'm sure you know, this topic has gotten a lot of disrespectful, abusive and overly-simplified

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

scalations. >>>- >>> >>>We expect a long transition period after that. By default, the >>>unload event is ignored, but different stakeholders are able to revert to >>>legacy behavior. Within enterprise, we expect the enterprise policy to be >&

Re: [blink-dev] Intent to Prototype & Ship: Clear-Site-Data header wildcard syntax

line. > ~ Ari Chivukula (Their/There/They're) > > > On Tue, Jul 18, 2023 at 1:59 PM Rick Byers wrote: > >> Seems like a pretty tiny addition to an already shipped feature. Just one >> question on future compat: >> >> On Mon, Jul 17, 2023 at 7:34 

Re: [blink-dev] Intent to Prototype & Ship: Clear Client Hints via Clear-Site-Data header

Seems like a pretty minor and straightforward addition to an already shipped feature to me. LGTM1 On Mon, Jul 17, 2023 at 4:39 PM Ari Chivukula wrote: > Updating subject to reflect intent. > > ~ Ari Chivukula (Their/There/They're) > > On Mon, Jul 17, 2023, 14:35 Ari Chivukula wrote: > >>

Re: [blink-dev] Intent to Prototype & Ship: Clear-Site-Data header wildcard syntax

Seems like a pretty tiny addition to an already shipped feature. Just one question on future compat: On Mon, Jul 17, 2023 at 7:34 AM Ari Chivukula wrote: > Contact emails > > aric...@chromium.org, miketa...@chromium.org, yoavwe...@chromium.org > > Specification > >

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

Seems like a great thing to experiment with! LGTM On Sat, Jul 15, 2023 at 7:33 AM Nidhi Jaju wrote: > Hi Mike, > > The proposed experiment is to run an A/B experiment on Canary/Dev, Beta, > and then 1% of Stable on M117. > > Best, > Nidhi > > On Sat, Jul 15, 2023 at 12:32 AM Mike Taylor >

Re: [blink-dev] Intent to Ship: [URL] Allow "%00" as a valid URL path

Agreed this is bugfix level and not "an API change". Of course bug fixes can also trigger compat issues, but it seems very unlikely to me that anyone could reasonably depend on chromium failing to parse a URL of this obscure form (when other engines don't). LGTM2 On Mon, Jul 17, 2023 at 2:25 PM

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

fully resolved and the > changes to not allow popups on page unload and to not allow synchronous > XHRs on page unload were shipped. Both of those changes followed > essentially the same plan I just laid out above, and so I think it's > reasonable to do the same thing here. > > Th

Re: [blink-dev] Intent to Ship: Private Aggregation API

On Wed, Jun 28, 2023 at 12:34 PM Alex Turner wrote: > > On Wed, Jun 28, 2023 at 11:53 AM Rick Byers wrote: > >> On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss >> wrote: >> >>> I wanted to comment on this intent with my spec mentor hat on. I >>> revi

Re: [blink-dev] Intent to Ship: Attribution Reporting API

t;> >> We went through and added a "compat" label for issues that we feel have >> compat risk. For the issues linked here, we are following up on those >> individually and will provide an update soon. >> > > Thanks! Going through the issues > <h

Re: [blink-dev] Intent to Ship (I2S): Protected Audience

Protected audiences seems like one of the most powerful and complex features ever added to Chromium, and I'll admit I've struggled to understand it at enough depth to do a decent API owner review. I carved out a few more hours this morning and am now comfortable giving my LGTM1 to ship. My

Re: [blink-dev] Intent to Remove: CSS property -webkit-highlight

%3ACSS=CSS >>> shows this has been used elsewhere (but I guess has just been useless in >>> clank?). >>> >>> That said, LGTM2. >>> >>> On 7/1/23 4:33 AM, Rick Byers wrote: >>> >>> Removing a prefixed API with no behavior should be

Re: [blink-dev] Intent to Remove: CSS property -webkit-highlight

Removing a prefixed API with no behavior should be trivial, thanks for the cleanup Stephen :-) However, the UseCounter is surprisingly high with lots of hits in HA: https://chromestatus.com/metrics/css/timeline/popularity/251. Just confirming that you looked at a sample of those hits and found

Re: [blink-dev] Intent to Ship: Permissions-Policy: unload

LGTM2 In addition to Yoav's comments I'll also add that it makes sense to me if WebKit and Gecko don't want this. They each have a lot more flexibility in how they avoid unload handlers, and WebKit already just doesn't fire them when they don't want to. Chromium's enterprise customer base means

Re: [blink-dev] Intent to Ship: RFC 7616 Digest auth: Support SHA-256, SHA-512-256 and user hashing

ny change at all. So the risk is limited to early-adopting servers > that have adopted the new thing but gotten it wrong. Or if we got it wrong. > :-) (No particular opinions on my end as to whether that makes it worth > flag-protecting.) > > On Mon, Jun 26, 2023 at 10:46 AM Rick Byers w

Re: [blink-dev] Intent to Ship: RFC 7616 Digest auth: Support SHA-256, SHA-512-256 and user hashing

nteresting rules around which paths an auth entry is scoped to. >>> >>> In terms of breakage risk, since this protocol is server-offer >>> / client-select, the client never sends the list of values it supports. >>> That means only servers that actually claim to support the n

  1   2   3   4   >