[blink-dev] Intent to Prototype: CSS text-box-trim and text-box-edge

We're resending I2P since the specification will change a lot after this discussion (https://github.com/w3c/csswg-drafts/issues/8829). For previous I2P, see this link

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

On Sat, Jan 6, 2024 at 3:05 AM Paul Jensen wrote: > Contact emails > > pauljen...@chromium.org > > > Explainer > > Ad slot size in real-time bidding signals fetch: > https://github.com/WICG/turtledove/pull/928 > > Update more interest group fields: Already covered by explainer >

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

I agree with Dave's take on the importance of not including extension scripts themselves, and Rick's take on how it is OK to include extension-injected main world scripts. One additional interop concern that's worth highlighting here is that the stack trace format itself is not compatible across

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

Thanks Thomas for all your work here! Your HTTP Archive survey seems promising to me: it sounds like there are no regressions, and you found some great places to perform outreach. (Hi Wesley!) I'm happy to LGTM this as soon as the privacy/security reviews are approved and you've picked a target

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

Wesley from Mux here. I saw the issue come by. We'd be happy those API's could get deprecated and unified into the new one. Our Media Chrome (library, not browser) implementation handles this gracefully, some code here

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

I opened a support ticket with Mux, and opened an issue for Clappr . On Wed, Jan 24, 2024 at 3:40 PM Thomas Guilbert wrote: > I've created a new ChromeStatus entry > , and requested the >

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

I've created a new ChromeStatus entry , and requested the privacy/security/debuggability gates for the deprecation trial. I audited a little more than 20 sites from the HTTP Archive. I've found a few JS player libraries that primarily use the

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

[blink-dev] Web-facing PSA: Allow setting IDP login status from same-site subresources

We have recently shipped the login status API to let identity providers (IdPs) (and, technically, other websites) tell Chrome when a user is logging in to or logging out from the website. We previously only allowed setting the login status on

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

create a PR for the code point change on the RFC draft, will work on there: https://github.com/vasilvv/tls-alps/pull/15, thanks. On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote: > Thanks, it will be helpful to make sure this is documented outside of > Chromium. I will

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

Just a few thoughts... I haven't seen a proposed implementation but I presume you are going to restrict this only to execution stacks in the main world? If you get an extension executing scripts in the main world how will you prevent the endpoint from knowing about the agent's execution

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

Thank you all for the feedback. I am going to open a ticket to discuss the expected behavior in shadow DOM and report the status back. Thanks, Siye On Tuesday, January 23, 2024 at 1:45:44 PM UTC-8 dba...@chromium.org wrote: > For what it's worth, some of the historical context around the 2009

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

Thanks, it will be helpful to make sure this is documented outside of Chromium. I will also chat with some folks on Microsoft’s end that both own server implementations and have more IETF experience to explore how we can help with moving things forward. From: Victor Tan Sent: Wednesday,

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

Does this: https://mozilla.github.io/standards-positions/#wasm-js-promise-integration count as an official positive signal? Francis On Wed, Jan 24, 2024 at 3:09 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Friday, January 5, 2024 at 7:25:28 PM UTC+1 Francis McCabe wrote: >

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

Contact emails issackj...@microsoft.com, seth.bren...@microsoft.com Explainer https://github.com/WICG/crash-reporting/issues/12 Specification

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

Rick, thanks for question, I will create a PR on the ALPS RFC draft to document the new code point regarding the early experiment. On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote: > On Wed, Jan 24, 2024 at 4:48 PM Rick Byers wrote: > >> Oof, I agree it's not good that the

Re: [blink-dev] Re: Intent to implement and ship: Allow elements with CSS display:contents to be focusable

On Wed, Jan 10, 2024 at 5:50 PM David Baron wrote: > > > On Wed, Jan 10, 2024 at 11:14 AM Yoav Weiss > wrote: > >> >> >> On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote: >> >> Contact emailsdba...@chromium.org >> >> ExplainerNone >> >>

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

LGTM3 /Daniel On 2024-01-24 11:45, Yoav Weiss (@Shopify) wrote: LGTM2 On Tuesday, January 23, 2024 at 11:17:35 AM UTC+1 Mike Taylor wrote: Thanks Liam. This seems fine to me given that both parties need to opt in. LGTM1 On 1/22/24 6:10 PM, Liam Brady wrote: Hi Mike,

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

On Wed, Jan 24, 2024 at 4:48 PM Rick Byers wrote: > 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

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

Also, what are the timelines you have in mind in terms of deprecation? On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell wrote: > Unreliable use counters sound scary. We base a lot of decisions off those. > So far they have only been shown to over-count though? But still, would be > great if

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

Unreliable use counters sound scary. We base a lot of decisions off those. So far they have only been shown to over-count though? But still, would be great if someone could get a grip on that bug and either fix it or make us understand what is going on. For this feature, what is the status of

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

Great, thank you! Yep, looks like the PR is about to land to me, I'm satisfied. LGTM1 On Wed, Jan 24, 2024 at 10:02 AM Paul Jensen wrote: > That spec PR has now been reviewed and approved by the Protected > Audience team and our spec mentor. Once a couple nits are addressed, I > imagine it'll

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: Protected Audience Ad slot size in real-time bidding signals fetch and update more interest group fields

That spec PR has now been reviewed and approved by the Protected Audience team and our spec mentor. Once a couple nits are addressed, I imagine 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

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

LGTM3 On Wed, Jan 24, 2024 at 1:45 PM Noam Rosenthal wrote: > Oh thanks for pointing it out! This wouldn't be a breaking change, > probably a test bug from previous changes, will fix that before shipping of > course. > > On Wed, Jan 24, 2024 at 12:31 PM domenic via Chromestatus < >

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

Oh thanks for pointing it out! This wouldn't be a breaking change, probably a test bug from previous changes, will fix that before shipping of course. On Wed, Jan 24, 2024 at 12:31 PM domenic via Chromestatus < admin+dome...@cr-status.appspotmail.com> wrote: > I found some interesting test

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

I found some interesting test failures at https://wpt.fyi/results/long-animation-frame/tentative/loaf-source-location-redirect.html?label=experimental=master . Do they represent anything worth worrying about, eg a potential breaking change? Assuming not, LGTM2. -- You received this message

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

LGTM1 On 1/17/24 9:32 AM, 'Noam Rosenthal' via blink-dev wrote: Updating that Mozilla gave an official positive signal: https://github.com/mozilla/standards-positions/pull/962 Updated the corresponding chromestatus field. On Monday, January 15, 2024 at 10:34:19 AM UTC Noam Rosenthal wrote:

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

Would you mind requesting reviews for the various gates (privacy, security, debuggability) for an OT/DT in your chromestatus entry? On 1/19/24 10:43 PM, Thomas Guilbert wrote: Contact emails tguilb...@chromium.org Explainer None Specification

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

LGTM3 On 1/24/24 11:24 AM, Yoav Weiss (@Shopify) wrote: LGTM2 On Tuesday, January 23, 2024 at 4:40:55 PM UTC+1 Rick Byers wrote: 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

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

On Friday, January 5, 2024 at 7:25:28 PM UTC+1 Francis McCabe wrote: This is an update to the previous intent-to-experiment (filled out a few more fields) Contact emails...@chromium.org Explainerhttps://github.com/WebAssembly/js-promise-integration/blob/main/

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

LGTM2 On Tuesday, January 23, 2024 at 11:17:35 AM UTC+1 Mike Taylor wrote: > Thanks Liam. This seems fine to me given that both parties need to opt in. > > LGTM1 > On 1/22/24 6:10 PM, Liam Brady wrote: > > Hi Mike, > > "crossOrigin=true" is just a typo. "crossOrigin" was the original naming >

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

LGTM2 On Tuesday, January 23, 2024 at 4:40:55 PM UTC+1 Rick Byers wrote: > 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