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

[Lingqi Chi]

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

.


Contact emails

lin...@chromium.org, ko...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-inline-3/#text-edges

https://drafts.csswg.org/css-inline-3/#leading-trim

* Note: the specification is out-of-date.

Summary

This feature includes two CSS properties,  text-box-trim and text-box-edge.

text-box-trim specifies whether start/end/both sides should be trimmed or
not, and text-box-edge specifies how each edge should be trimmed.

These properties allow developers to have precise control over spacing, and
ensure font metrics are respected during layout in terms of spacing.

Blink component

Blink>Layout>Inline


Motivation

Developers and designers sometimes find the texts are not visually aligned,
as browsers would pad extra spaces to ensure line height without taking the
font-reserved space into account.

This feature aims to improve this.



Initial public proposal

https://github.com/w3c/csswg-drafts/issues/5426

See also https://github.com/w3c/csswg-drafts/issues/8829 which concludes
the latest decision.

TAG review

None

TAG review status

Not applicable

RisksInteroperability and Compatibility

None

Gecko: No signal

WebKit: https://webkit.org/css-status/#property-text-box-edge

https://webkit.org/blog/13839/release-notes-for-safari-technology-preview-163/


Web developers: No signals

The community wants browsers to implement and unify this property.
https://forum.figma.com/t/text-box-trim-edge-inconsistency-with-browser/52463


Other signals:

WebView application risks

No


Debuggability

None


Is this feature fully tested by web-platform-tests

?

No. Will add more.

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

We do not need an A/B test for it.

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1411581

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5174589850648576

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B99URLC-V9Zrscj8F%3D%3DkGmnmp0OmNhGB11Uyy%2B-y5ZExSK5MQ%40mail.gmail.com

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CA%2B99UR%2BKq5ErMeyBOF3XWHUj6HiqkG7wiq%2BWsjwZBhg4EZ4Gqg%40mail.gmail.com.

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

[Domenic Denicola]

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
> 
>
>
> Specification
>
> Ad slot size in real-time bidding signals fetch:
> https://github.com/WICG/turtledove/pull/954
>
> Update more interest group fields:
> https://github.com/WICG/turtledove/pull/907
> https://github.com/WICG/turtledove/pull/953
>
>
> Summary
>
> Ad slot size in real-time bidding signals fetch:
>
> Protected Audience ad selection auctions allow buyers to fetch real-time
> signals from their key-value server.  Besides being used for calculating
> bid prices, these signals can also be used for prioritizing and filtering
> potential ad candidates.  The more ad candidate filtration and
> prioritization that we can enable, the more performant the auction is (e.g.
> less browser resource utilization) and the higher the quality of the chosen
> ad candidates is.  This feature extends the signals about the page where
> the ad will be displayed from just its domain name, to also include the
> size of the ad slots on the page, which is a very useful signal for
> filtering out ads that cannot be rendered in that slot size.
>
> Allow updating interest group’s userBiddingSignals and executionMode:
>
> Protected Audience has always supported updating interest group fields,
> but for historical reasons did not support updating the interest group
> field named userBiddingSignals, and for no obvious reason did not support
> updating executionMode. This change is a small extension to Protected
> Audience interest group updating to support updating these fields, making
> the API more useful by being able to update/refresh the fields with more up
> to date information.
>
>
> Blink component
>
> Blink>InterestGroups
> 
>
>
> TAG review
>
> The parent proposal, Protected Audience, is still pending:
> https://github.com/w3ctag/design-reviews/issues/723
>

It appears the TAG responded to this review on 2023-11-28, but nobody has
answered their questions yet. Could you do so?


>
> TAG review status
>
> Pending
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> These are both optional new features so we do not expect them to cause
> compatibility breakage.
>
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> , and in the
> Webkit forum here
> .
>
>
> Web developers:
>
> Ad slot size in real-time bidding signals fetch: Interest from multiple
> adtechs here .
>
> Update more interest group fields: Interest from adtech here
> .
>
>
> Debuggability
>
> Ad slot size in real-time bidding signals fetch: The extra runAdAuction()
> and joinAdInterestGroup() parameters should be visible in DevTools, as
> should the real-time bidding signal fetches in the DevTools network panel.
>
> Update more interest group fields: The updates should be visible in
> DevTools’ Application Storage Interest Group section.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> It will be supported on all platforms that support Protected Audience, so
> all but WebView.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> We plan to land web-platform-tests for both features shortly.  Some have
> already landed
> 
> .
>
>
> Flag name on chrome://flags
>
> None
>
>
> Finch feature name
>
> EnableIFrameAdAuctionHeaders, EnableUpdatingExecutionModeToFrozenContext,
> EnableUpdatingUserBiddingSignals
>
>
> Requires code in //chrome?
>
> False
>
>
> Estimated milestones
>
> Shipping on desktop and Android in M121.
>
> Anticipated spec changes
>
> None related to these features.
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5090856430469120
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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

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

[Domenic Denicola]

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 browsers. However, I
don't think that should block this intent. It is already exposed throughout
the web platform (via the `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 do wish that one day browsers would get together and standardize the
stack trace format. https://github.com/tc39/proposal-error-stacks is one
attempt at that, but it has been largely dormant for 3 years.

On Thu, Jan 25, 2024 at 5:59 AM Rick Byers  wrote:

> 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
> working on it! Don't hesitate to reach out if I can help unblock progress
> in any way.
>
> What you have listed as a spec is more of a design doc so you'll
> eventually need a formal spec. But the reporting spec editor @Ian Clelland
>  mentioned over breakfast to me today that he was
> helping to support this work, so that's great to hear.
>
> Dave's question about extensions in the main thread and privacy
> implications is a good one. My initial personal take is that we probably
> shouldn't report from extension isolated worlds, but when an extension
> injects script into the main world, I think I can argue that they're
> explicitly informing the site developer about their presence. In practice I
> believe sites can detect such extensions already if suitably motivated (eg.
> hook into the prototype of various APIs and identify their calling patterns
> or look at JS exception stack traces). I can see an argument for not giving
> sites easy access to such information in real-time and wonder if this has
> come up already for the self-profiling API proposal
> ? But for an asynchronous
> crash report sent only after the page has been shut down, I personally
> don't think it's a threat we should be trying to defend against. I'd go
> even further and say that if a site is hanging or crashing only under the
> presence of extension-injected code in the main world, then that's critical
> information for the site owner to know from a customer support perspective.
>
> Rick
>
> On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska 
> wrote:
>
>> 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
>> environment such as what extensions they have installed?
>> How do you know from the IO thread what the main thread isolate is?
>> (blink::MainThreadIsolate is deprecated, please don't use it).
>> How do document policies work across same origin documents? What realms
>> are you checking that the policy applies, do you walk the stack looking at
>> realms and checking if the policies apply? Or is it the current realm or
>> incumbent realm or what?
>>
>> dave.
>>
>> On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>> issackj...@microsoft.com, seth.bren...@microsoft.com
>>>
>>> Explainer
>>> https://github.com/WICG/crash-reporting/issues/12
>>>
>>> Specification
>>>
>>> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>>>
>>> Summary
>>>
>>> This feature captures the JS call stack when a web page becomes
>>> unresponsive due to JavaScript code running an infinite loop or other very
>>> long computation. This helps developers to identify the cause of the
>>> unresponsiveness and fix it more easily. The JS call stack is included in
>>> the crash reporting API when the reason is unresponsive.
>>>
>>>
>>> Blink component
>>> Blink>ReportingObserver
>>> 
>>>
>>> Motivation
>>>
>>> When a web page becomes unresponsive, it's often because of JavaScript
>>> code which is busy running an infinite loop or other very long computation.
>>> When a developer receives a report from the crash reporting API, and the
>>> reason is unresponsive, it would be very helpful to include the JS call
>>> stack from when the page was deemed unresponsive. This would let the
>>> website developer more easily find the find and fix the problem. What
>>> happens instead? The page reports that it was 

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

[Domenic Denicola]

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 experiment timeline.

On Thu, Jan 25, 2024 at 10:00 AM Wesley Luyten 
wrote:

> 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
>
> https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636
>
> The Vimeo player uses a variant of https://github.com/bdougherty/BigScreen,
> a similar popular library is https://github.com/sindresorhus/screenfull
>
> Just thought to mention it but iOS never supported the generic fullscreen
> API until very recent
> https://twitter.com/jensimmons/status/1717937227190460797
> It always required the webkit prefixed API on the video element (not any
> other element like a div etc )
> Y'all are aware of that?
> On Wednesday, January 24, 2024 at 6:23:16 PM UTC-6 Thomas Guilbert wrote:
>
>> 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
>>> 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 `webkitSupportsFullscreen`
>>> and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of
>>> PlayerJS.
>>> I found websites with a fullscreen button for Mux and PlayerJS, and they
>>> behaved as expected on a build of Chrome without the APIs. The one site I
>>> found using Clappr that had a fullscreen button did not work, both on the
>>> custom build and the latest canary.
>>>
>>> It also seems like some version of the Vimeo CDN player uses
>>> `webkitEnterFullscreen`:
>>> https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js*.*
>>>
>>> Thanks,
>>> Thomas
>>>
>>> On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola 
>>> wrote:
>>>


 On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert 
 wrote:

> Good point about the most used APIs being the boolean properties! The
> APIs are now only aliases for the standard non-prefixed fullscreen APIs 
> (see
> this code for the current implementation
> ),
> and therefore aren't much of a burden to maintain.
>
> I opened a WebKit standards position here:
> https://github.com/WebKit/standards-positions/issues/306
>
> I unfortunately do not have access to edit the listed ChromeStatus
> entry, and the current owner no longer works on Chromium. Should I create 
> a
> new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed
> Fullscreen API")? I think the current ChromeStatus entry also covers this
> API
> 
> which I am not trying to deprecate in this Intent.
>

 Yeah, I think a new feature is a good idea. The old feature seems to be
 for the *addition* of the prefixed fullscreen API properties back in
 Chrome 15, whereas a *deprecation/removal* has a different set of
 fields, if I understand correctly.


>
> What's a reasonable sample size of HTTP Archive sites to audit? Should
> this be a complement/precursor to the proposed Deprecation Trial, or would
> this sampling be enough?
>

 I recall +Philip Jägenstedt having done some computations in the past
 based on what would actually be statistically significant. But, I couldn't
 find them in this documentation
  (or
 the linked document
 ).
 So, I'll just state that I would be happy with 20 sites.

 I think the deprecation trial is a great complement to have in any
 case, so I would treat this as a precursor. It's always safest to have the
 option for web developers to un-break their sites. The purpose of the HTTP
 Archive investigation is mostly to see if we can find major shared
 patterns, to say things like "all sites using this code will be broken" or
 

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

[Wesley Luyten]

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 
https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636

The Vimeo player uses a variant of https://github.com/bdougherty/BigScreen, 
a similar popular library is https://github.com/sindresorhus/screenfull

Just thought to mention it but iOS never supported the generic fullscreen 
API until very recent 
https://twitter.com/jensimmons/status/1717937227190460797
It always required the webkit prefixed API on the video element (not any 
other element like a div etc )
Y'all are aware of that?
On Wednesday, January 24, 2024 at 6:23:16 PM UTC-6 Thomas Guilbert wrote:

> 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 
>> 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 `webkitSupportsFullscreen` 
>> and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of 
>> PlayerJS.
>> I found websites with a fullscreen button for Mux and PlayerJS, and they 
>> behaved as expected on a build of Chrome without the APIs. The one site I 
>> found using Clappr that had a fullscreen button did not work, both on the 
>> custom build and the latest canary.
>>
>> It also seems like some version of the Vimeo CDN player uses 
>> `webkitEnterFullscreen`: 
>> https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js*.*
>>
>> Thanks,
>> Thomas
>>
>> On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola  
>> wrote:
>>
>>>
>>>
>>> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert  
>>> wrote:
>>>
 Good point about the most used APIs being the boolean properties! The 
 APIs are now only aliases for the standard non-prefixed fullscreen APIs 
 (see 
 this code for the current implementation 
 ),
  
 and therefore aren't much of a burden to maintain.

 I opened a WebKit standards position here: 
 https://github.com/WebKit/standards-positions/issues/306

 I unfortunately do not have access to edit the listed ChromeStatus 
 entry, and the current owner no longer works on Chromium. Should I create 
 a 
 new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed 
 Fullscreen API")? I think the current ChromeStatus entry also covers this 
 API 
 
  
 which I am not trying to deprecate in this Intent.

>>>
>>> Yeah, I think a new feature is a good idea. The old feature seems to be 
>>> for the *addition* of the prefixed fullscreen API properties back in 
>>> Chrome 15, whereas a *deprecation/removal* has a different set of 
>>> fields, if I understand correctly.
>>>  
>>>

 What's a reasonable sample size of HTTP Archive sites to audit? Should 
 this be a complement/precursor to the proposed Deprecation Trial, or would 
 this sampling be enough?

>>>
>>> I recall +Philip Jägenstedt having done some computations in the past 
>>> based on what would actually be statistically significant. But, I couldn't 
>>> find them in this documentation 
>>>  (or 
>>> the linked document 
>>> ).
>>>  
>>> So, I'll just state that I would be happy with 20 sites.
>>>
>>> I think the deprecation trial is a great complement to have in any case, 
>>> so I would treat this as a precursor. It's always safest to have the option 
>>> for web developers to un-break their sites. The purpose of the HTTP Archive 
>>> investigation is mostly to see if we can find major shared patterns, to say 
>>> things like "all sites using this code will be broken" or "all sites using 
>>> this code will be slightly worse, but basically fine", or even "all sites 
>>> using this open-source library will be broken, but we can send them a PR 
>>> and that will create a clear upgrade path".
>>>  
>>>

 Thank you,
 Thomas

 On Sun, Jan 21, 2024 at 7:56 PM Domenic Denicola  
 wrote:

> It would be very exciting to clean this up! I have some questions that 
> 

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

[Thomas Guilbert]

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
> 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 `webkitSupportsFullscreen`
> and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of
> PlayerJS.
> I found websites with a fullscreen button for Mux and PlayerJS, and they
> behaved as expected on a build of Chrome without the APIs. The one site I
> found using Clappr that had a fullscreen button did not work, both on the
> custom build and the latest canary.
>
> It also seems like some version of the Vimeo CDN player uses
> `webkitEnterFullscreen`:
> https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js*.*
>
> Thanks,
> Thomas
>
> On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola 
> wrote:
>
>>
>>
>> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert 
>> wrote:
>>
>>> Good point about the most used APIs being the boolean properties! The
>>> APIs are now only aliases for the standard non-prefixed fullscreen APIs (see
>>> this code for the current implementation
>>> ),
>>> and therefore aren't much of a burden to maintain.
>>>
>>> I opened a WebKit standards position here:
>>> https://github.com/WebKit/standards-positions/issues/306
>>>
>>> I unfortunately do not have access to edit the listed ChromeStatus
>>> entry, and the current owner no longer works on Chromium. Should I create a
>>> new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed
>>> Fullscreen API")? I think the current ChromeStatus entry also covers this
>>> API
>>> 
>>> which I am not trying to deprecate in this Intent.
>>>
>>
>> Yeah, I think a new feature is a good idea. The old feature seems to be
>> for the *addition* of the prefixed fullscreen API properties back in
>> Chrome 15, whereas a *deprecation/removal* has a different set of
>> fields, if I understand correctly.
>>
>>
>>>
>>> What's a reasonable sample size of HTTP Archive sites to audit? Should
>>> this be a complement/precursor to the proposed Deprecation Trial, or would
>>> this sampling be enough?
>>>
>>
>> I recall +Philip Jägenstedt  having done some
>> computations in the past based on what would actually be statistically
>> significant. But, I couldn't find them in this documentation
>>  (or
>> the linked document
>> ).
>> So, I'll just state that I would be happy with 20 sites.
>>
>> I think the deprecation trial is a great complement to have in any case,
>> so I would treat this as a precursor. It's always safest to have the option
>> for web developers to un-break their sites. The purpose of the HTTP Archive
>> investigation is mostly to see if we can find major shared patterns, to say
>> things like "all sites using this code will be broken" or "all sites using
>> this code will be slightly worse, but basically fine", or even "all sites
>> using this open-source library will be broken, but we can send them a PR
>> and that will create a clear upgrade path".
>>
>>
>>>
>>> Thank you,
>>> Thomas
>>>
>>> On Sun, Jan 21, 2024 at 7:56 PM Domenic Denicola 
>>> wrote:
>>>
 It would be very exciting to clean this up! I have some questions that
 might help clarify the cost-benefit analysis.

 On Sat, Jan 20, 2024 at 6:43 AM Thomas Guilbert 
 wrote:

> Contact emails
>
> tguilb...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled
>
> Summary
> There was an attempt in 2014
> 
> to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen
> APIs. This meant removing the following APIs from HTMLVideoElement:
>
> readonly attribute boolean webkitSupportsFullscreen;
> readonly attribute boolean webkitDisplayingFullscreen;
> void webkitEnterFullscreen();
> void webkitExitFullscreen();
> // Note the different capitalization of the "S" in FullScreen.
> void webkitEnterFullScreen();
> void webkitExitFullScreen();
>
>
 How "expensive" is it to support these APIs? For 

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

[Thomas Guilbert]

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 `webkitSupportsFullscreen`
and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of
PlayerJS.
I found websites with a fullscreen button for Mux and PlayerJS, and they
behaved as expected on a build of Chrome without the APIs. The one site I
found using Clappr that had a fullscreen button did not work, both on the
custom build and the latest canary.

It also seems like some version of the Vimeo CDN player uses
`webkitEnterFullscreen`: https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js
*.*

Thanks,
Thomas

On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola 
wrote:

>
>
> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert 
> wrote:
>
>> Good point about the most used APIs being the boolean properties! The
>> APIs are now only aliases for the standard non-prefixed fullscreen APIs (see
>> this code for the current implementation
>> ),
>> and therefore aren't much of a burden to maintain.
>>
>> I opened a WebKit standards position here:
>> https://github.com/WebKit/standards-positions/issues/306
>>
>> I unfortunately do not have access to edit the listed ChromeStatus entry,
>> and the current owner no longer works on Chromium. Should I create a new
>> feature (titled "Deprecation of HTMLVideoElement-specific Prefixed
>> Fullscreen API")? I think the current ChromeStatus entry also covers this
>> API
>> 
>> which I am not trying to deprecate in this Intent.
>>
>
> Yeah, I think a new feature is a good idea. The old feature seems to be
> for the *addition* of the prefixed fullscreen API properties back in
> Chrome 15, whereas a *deprecation/removal* has a different set of fields,
> if I understand correctly.
>
>
>>
>> What's a reasonable sample size of HTTP Archive sites to audit? Should
>> this be a complement/precursor to the proposed Deprecation Trial, or would
>> this sampling be enough?
>>
>
> I recall +Philip Jägenstedt  having done some
> computations in the past based on what would actually be statistically
> significant. But, I couldn't find them in this documentation
>  (or
> the linked document
> ).
> So, I'll just state that I would be happy with 20 sites.
>
> I think the deprecation trial is a great complement to have in any case,
> so I would treat this as a precursor. It's always safest to have the option
> for web developers to un-break their sites. The purpose of the HTTP Archive
> investigation is mostly to see if we can find major shared patterns, to say
> things like "all sites using this code will be broken" or "all sites using
> this code will be slightly worse, but basically fine", or even "all sites
> using this open-source library will be broken, but we can send them a PR
> and that will create a clear upgrade path".
>
>
>>
>> Thank you,
>> Thomas
>>
>> On Sun, Jan 21, 2024 at 7:56 PM Domenic Denicola 
>> wrote:
>>
>>> It would be very exciting to clean this up! I have some questions that
>>> might help clarify the cost-benefit analysis.
>>>
>>> On Sat, Jan 20, 2024 at 6:43 AM Thomas Guilbert 
>>> wrote:
>>>
 Contact emails

 tguilb...@chromium.org

 Explainer

 None

 Specification

 https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled

 Summary
 There was an attempt in 2014
 
 to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen
 APIs. This meant removing the following APIs from HTMLVideoElement:

 readonly attribute boolean webkitSupportsFullscreen;
 readonly attribute boolean webkitDisplayingFullscreen;
 void webkitEnterFullscreen();
 void webkitExitFullscreen();
 // Note the different capitalization of the "S" in FullScreen.
 void webkitEnterFullScreen();
 void webkitExitFullScreen();


>>> How "expensive" is it to support these APIs? For example, if some of
>>> them are just straight-up aliases of standard APIs, then the benefit of
>>> removal might be low. Whereas if, for example, these prefixed "enter
>>> fullscreen" APIs have different behavior than the standardized
>>> requestFullscreen() API, then supporting the prefixed variants feels

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

[Rick Byers]

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
working on it! Don't hesitate to reach out if I can help unblock progress
in any way.

What you have listed as a spec is more of a design doc so you'll eventually
need a formal spec. But the reporting spec editor @Ian Clelland
 mentioned over breakfast to me today that he was
helping to support this work, so that's great to hear.

Dave's question about extensions in the main thread and privacy
implications is a good one. My initial personal take is that we probably
shouldn't report from extension isolated worlds, but when an extension
injects script into the main world, I think I can argue that they're
explicitly informing the site developer about their presence. In practice I
believe sites can detect such extensions already if suitably motivated (eg.
hook into the prototype of various APIs and identify their calling patterns
or look at JS exception stack traces). I can see an argument for not giving
sites easy access to such information in real-time and wonder if this has
come up already for the self-profiling API proposal
? But for an asynchronous crash
report sent only after the page has been shut down, I personally don't
think it's a threat we should be trying to defend against. I'd go even
further and say that if a site is hanging or crashing only under the
presence of extension-injected code in the main world, then that's critical
information for the site owner to know from a customer support perspective.

Rick

On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska  wrote:

> 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
> environment such as what extensions they have installed?
> How do you know from the IO thread what the main thread isolate is?
> (blink::MainThreadIsolate is deprecated, please don't use it).
> How do document policies work across same origin documents? What realms
> are you checking that the policy applies, do you walk the stack looking at
> realms and checking if the policies apply? Or is it the current realm or
> incumbent realm or what?
>
> dave.
>
> On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>> issackj...@microsoft.com, seth.bren...@microsoft.com
>>
>> Explainer
>> https://github.com/WICG/crash-reporting/issues/12
>>
>> Specification
>>
>> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>>
>> Summary
>>
>> This feature captures the JS call stack when a web page becomes
>> unresponsive due to JavaScript code running an infinite loop or other very
>> long computation. This helps developers to identify the cause of the
>> unresponsiveness and fix it more easily. The JS call stack is included in
>> the crash reporting API when the reason is unresponsive.
>>
>>
>> Blink component
>> Blink>ReportingObserver
>> 
>>
>> Motivation
>>
>> When a web page becomes unresponsive, it's often because of JavaScript
>> code which is busy running an infinite loop or other very long computation.
>> When a developer receives a report from the crash reporting API, and the
>> reason is unresponsive, it would be very helpful to include the JS call
>> stack from when the page was deemed unresponsive. This would let the
>> website developer more easily find the find and fix the problem. What
>> happens instead? The page reports that it was terminated due to being
>> unresponsive, but the developer of the page has no further information
>> about how to fix the problem.
>>
>>
>> Initial public proposal
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>>
>> TAG review
>> None
>>
>> TAG review status
>> Pending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> *Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?*
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>> No
>>
>> Flag name on chrome://flags
>> None
>>
>> Finch feature name
>> None
>>
>> Non-finch justification
>> None
>>
>> Requires code in //chrome?

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

[Christian Biesinger]

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 toplevel loads or
for subresources which are same-origin with all their ancestors, both when
using the JavaScript API and when using the HTTP header.

As described here , we now
also allow same-site (same eTLD+1) subresources to set a login status (for
the origin of the subresource). This is useful for IdPs where the IdP login
happens on one subdomain, but the FedCM endpoint is on a different
subdomain. To make sure that FedCM works correctly, the login status needs
to be set on the FedCM subdomain.

The change has been approved by the Chrome Web Platform security and
privacy teams and will ship in Chrome 122.

Spec change: https://github.com/fedidcg/FedCM/pull/538

WPT tests added in
https://chromium-review.googlesource.com/c/chromium/src/+/5207174

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHOLmKkgNtmySMj65%3D%3DAJ8HwkWkHHuarC_n2EcahYycAg%40mail.gmail.com.

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

[Victor Tan]

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 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, January 24, 2024 9:00 AM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; blink-dev <
> blink-dev@chromium.org>; Erik Anderson ; 
> Chris Harrelson ; David Benjamin <
> david...@chromium.org>; Mike Taylor ; Victor Tan <
> victor...@chromium.org>; Rick Byers 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> You don't often get email from victor...@chromium.org. Learn why this is 
> important 
>
> 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 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 shipping on the existence of some specification for everything 
> necessary for a compatible implementation in a forum that ensures IP 
> protection. While this isn't typically an adoption barrier for many 
> companies, I know it has been in the past for some (including Microsoft). 
> This doesn't mean we have to block on getting consensus in the "right" 
> standards venue, we can just do a monkey-patch spec in a venue like the 
> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
> contribution. Then we can ship it as an "incubation" while doing the 
> standards maturation work in parallel. Erik, can you comment on the extent 
> to which such incubation spec work would help with Microsoft adoption?
>
>  
>
> Victor, is there any chance you can throw something together quickly (spec 
> PR or monkey-patch) that would cover the gaps in what's necessary for 
> compatible implementations? This particular delta seems very tiny and 
> straightforward to me, so I was originally thinking I'd just approve it. 
> But in principle I don't think we should be continuing to approve changes 
> to APIs which we realize are struggling with adoption due to the standards 
> work not quite being up to our I2S bar.
>
>  
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>
>   
>
>  
>
> Erik, thank you for your offer of help on the standardization front! It 
> definitely sounds to me like we should be pushing on the full standards 
> effort in parallel to this specific intent. Having Microsoft and Google 
> work together on that would hopefully be able to accelerate it.
>
>  
>
> Rick
>
>  
>
>  
>
> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> To be clarify,  currently David is not working on the standardizing ALPS 
> feature.   
>
>  
>
> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>
> Hi Erik, 
>
> We are actively working on it, but we need to put more efforts to 
> standardization. 
>
> In the last serval IETF, David is the only person is talking about the 
> ALPS feature.  We'd glad to combine more efforts to move it forward to 
> standardization.
>
>  
>
> Bests,
>
> Victor 
>
> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>
> Is the ALPS draft being actively worked on?
>
>  
>
> Various teams at Microsoft that own web sites leveraging client hints have 
> expressed interest in using it, but the lack of a finalized standard has 
> significantly slowed conversations with the teams that own the server code 
> that would need to add support first.
>
>  
>
> Are you looking for help in moving standardization forward?
>
>  
>
> *From:* Yoav Weiss (@Shopify)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.org>; David Benjamin ; Mike Taylor 
> 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> Is the old code point defined somewhere? Would it be possible to add such 
> a definition to one of the I-Ds? Or is this something that's not 
> traditionally defined in IETF drafts?
>
>  
>
> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  wrote:
>
> Currently, It's on the code: 
> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
>
> Once we 

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

[Dave Tapuska]

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
environment such as what extensions they have installed?
How do you know from the IO thread what the main thread isolate is?
(blink::MainThreadIsolate is deprecated, please don't use it).
How do document policies work across same origin documents? What realms are
you checking that the policy applies, do you walk the stack looking at
realms and checking if the policies apply? Or is it the current realm or
incumbent realm or what?

dave.

On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
> issackj...@microsoft.com, seth.bren...@microsoft.com
>
> Explainer
> https://github.com/WICG/crash-reporting/issues/12
>
> Specification
>
> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>
> Summary
>
> This feature captures the JS call stack when a web page becomes
> unresponsive due to JavaScript code running an infinite loop or other very
> long computation. This helps developers to identify the cause of the
> unresponsiveness and fix it more easily. The JS call stack is included in
> the crash reporting API when the reason is unresponsive.
>
>
> Blink component
> Blink>ReportingObserver
> 
>
> Motivation
>
> When a web page becomes unresponsive, it's often because of JavaScript
> code which is busy running an infinite loop or other very long computation.
> When a developer receives a report from the crash reporting API, and the
> reason is unresponsive, it would be very helpful to include the JS call
> stack from when the page was deemed unresponsive. This would let the
> website developer more easily find the find and fix the problem. What
> happens instead? The page reports that it was terminated due to being
> unresponsive, but the developer of the page has no further information
> about how to fix the problem.
>
>
> Initial public proposal
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> TAG review
> None
>
> TAG review status
> Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> No
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4731248572628992
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com
> 
> .
>

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com.

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

['Siye Liu' via blink-dev]

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 
> changes is in WebApps TPAC 2009 minutes 
>  and Anne's 
> folllowup email to www-style 
> .
>
> -David
>
> On Tue, Jan 23, 2024 at 2:31 PM 'Dan Clark' via blink-dev <
> blin...@chromium.org> wrote:
>
>> For the shadow DOM scenario, have we started the spec conversation about 
>> what behavior we want to end up at? I find the Gecko behavior a bit 
>> suspicious since it's piercing into potentially-closed shadow trees without 
>> having a prior reference to them. Maybe caretPositionFromPoint should not 
>> pierce shadow DOMs and instead support shadows by being on 
>> DocumentOrShadowRoot. That said, since this is already shipped in Gecko it 
>> could be hard to reverse course.
>>
>> If the shadow DOM question hasn't been discussed in standards yet I think 
>> it's worth kicking that off in parallel with prototyping, so it doesn't end 
>> up being a barrier to shipping the full implementation later on. A lot of 
>> the developer feedback has been about how caretRangeFromPoint doesn't 
>> work with shadows so it seems like this is of central importance for the 
>> API.
>>
>> -- Dan
>>
>> On Thursday, January 18, 2024 at 6:13:48 AM UTC-8 Daniel Bratell wrote:
>>
>>> Sounds like something that should be reflected in the specs. Again, not 
>>> directly related to this Intent, but maybe something that should happen in 
>>> parallel.
>>>
>>> /Daniel
>>> On 2024-01-17 23:38, 'Siye Liu' via blink-dev wrote:
>>>
>>> Blink has similar concept called "affinity" when placing caret at 
>>> wrapped line. definition: 
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/visible_position.h;l=39-54
>>>  
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Wednesday, January 17, 2024 at 6:35:14 AM UTC-8 Daniel Bratell wrote:
>>>
 This is not directly related to this one function but more to the whole 
 API. I quickly skimmed the spec and I could not find out how it handles 
 line breaks which make caret positions ambigious?

 When you press the END key at one line, and the HOME key at the 
 following line your caret DOM position can be the same, but the visual 
 caret positions should be different, and so should certain actions like 
 arrow-down and arrow-up.

 When developing code to handle this in Opera, I solved it by letting 
 carets know if they were connected forward or backwards (basically a bool) 
 in the dom element, but maybe this is solved in some other way now?

 /Daniel
 On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:

 Hi Brian, 

 To answer your question,
 1. This prototype only covers the main dom scenario (
 https://crbug.com/388976). Shadow dom scenario is tracked in 
 https://crbug.com/1514810.
 2. The prototype should have similar behavior as caretRangeFromPoint's 
 implementation in Blink (when the point is over an input element, the 
 returned CaretPosition should be the nearest ancestor of the input 
 element) 
 because I expect both APIs share same hit testing logic under the hood.

 Once the prototype is ready for dev trial, we can discuss further about 
 improving current implementation in both caretRangeFromPoint and 
 caretPositionFromPoint in Blink.


 Thanks,
 Siye

 On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:

 Hi,

 Will this also cover the behavioral differences between 
 caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as 
 implemented in Blink such as:

 1. caretPositionFromPoint in Gecko digs into shadow DOM elements 
 whereas caretRangeFromPoint in Blink does not.
 2. When the point is over a text input element, caretPositionFromPoint 
 in Gecko returns the text input element and offset into it but 
 caretRangeFromPoint in Blink returns the nearest ancestor of the text 
 input 
 element. (Note that caretRangeFromPoint in Webkit returns the text input 
 element but always returns a zero offset into it.)

 Thanks,

 Brian

 2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

 Contact emails 
 si...@microsoft.com, sa...@microsoft.com

 Explainer
 None

 Specification
 https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

 Summary 

 This new API allows users to get current caret position from a given 
 screen point. The API returns a CaretPosition object which represents the 
 caret 

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

['Erik Anderson' via blink-dev]

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, January 24, 2024 9:00 AM
To: blink-dev 
Cc: Yoav Weiss ; blink-dev ; 
Erik Anderson ; Chris Harrelson 
; David Benjamin ; Mike Taylor 
; Victor Tan ; Rick Byers 

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

You don't often get email from 
victor...@chromium.org. Learn why this is 
important
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 
mailto:rby...@chromium.org>> 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 downsides to this. Our blink process is generally to block 
shipping on the existence of some specification for everything necessary for a 
compatible implementation in a forum that ensures IP protection. While this 
isn't typically an adoption barrier for many companies, I know it has been in 
the past for some (including Microsoft). This doesn't mean we have to block on 
getting consensus in the "right" standards venue, we can just do a monkey-patch 
spec in a venue like the WICG, or an unlanded PR in a formal WG where the PR 
counts as an IP contribution. Then we can ship it as an "incubation" while 
doing the standards maturation work in parallel. Erik, can you comment on the 
extent to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec PR 
or monkey-patch) that would cover the gaps in what's necessary for compatible 
implementations? This particular delta seems very tiny and straightforward to 
me, so I was originally thinking I'd just approve it. But in principle I don't 
think we should be continuing to approve changes to APIs which we realize are 
struggling with adoption due to the standards work not quite being up to our 
I2S bar.

+1 to defining these codepoints somewhere. Where are such codepoints typically 
defined? I'd have assumed they'd go into one of the relevant I-Ds..


Erik, thank you for your offer of help on the standardization front! It 
definitely sounds to me like we should be pushing on the full standards effort 
in parallel to this specific intent. Having Microsoft and Google work together 
on that would hopefully be able to accelerate it.

Rick


On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
To be clarify,  currently David is not working on the standardizing ALPS 
feature.

On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
Hi Erik,
We are actively working on it, but we need to put more efforts to 
standardization.
In the last serval IETF, David is the only person is talking about the ALPS 
feature.  We'd glad to combine more efforts to move it forward to 
standardization.

Bests,
Victor
On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
Is the ALPS draft being actively worked on?

Various teams at Microsoft that own web sites leveraging client hints have 
expressed interest in using it, but the lack of a finalized standard has 
significantly slowed conversations with the teams that own the server code that 
would need to add support first.

Are you looking for help in moving standardization forward?

From: Yoav Weiss (@Shopify) mailto:yoav...@chromium.org>>
Sent: Monday, January 22, 2024 7:39 AM
To: Victor Tan mailto:vict...@chromium.org>>
Cc: blink-dev mailto:blin...@chromium.org>>; Chris 
Harrelson mailto:chri...@chromium.org>>; David Benjamin 
mailto:davi...@chromium.org>>; Mike Taylor 
mailto:mike...@chromium.org>>
Subject: Re: [blink-dev] Re: Intent to Ship: New ALPS code point

Is the old code point defined somewhere? Would it be possible to add such a 
definition to one of the I-Ds? Or is this something that's not traditionally 
defined in IETF drafts?

On Mon, Jan 22, 2024 at 4:03 PM Victor Tan 
mailto:vict...@chromium.org>> wrote:
Currently, It's on the code: 
https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
Once we standardize the ALPS RFC draft, we can finalize the value.  Hope this 
helps.
On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote:
Thanks for clarifying. Last question: where in the specifications is the new 
17613 code point documented?

On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor 
mailto:mike...@chromium.org>> wrote:

In our OWNERS 

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

[Francis McCabe]

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:
>
> 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/
> proposals/js-promise-integration/Overview.md
>
> Specificationhttps://github.com/WebAssembly/js-promise-
> integration/blob/main/proposals/js-promise-integration/Overview.md
>
> Summary
>
> Stack Switching denotes a technology that allows programs to suspend and
> resume computation. This is an active area that is part of the WebAssembly
> standards track. See https://github.com/WebAssembly/stack-switching and
> https://github.com/WebAssembly/meetings/tree/main/stack. This particular
> feature refers to the integration between JavaScript Promises and stack
> switching. This is described in more detail in https://docs.google.com/
> document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#
>
>
> Blink componentBlink>JavaScript>WebAssembly
> 
>
> Search tagsstack switching
> , Promise
> , JSPI
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> This spec is backed by a standardization effort. We do not plan to ship
> the JSPI until it has been standardized by the W3C Wasm WG. However, post
> standardization, we will depend on all browsers implementing the standard.
>
>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627)
> Mozilla have started their own imlementation
>
>
> That doesn't count as a positive signal. Please file for official signals
>  (but that is not blocking for this OT).
>
>
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Goals for experimentation
>
> This specification is getting close to finalization. We would like
> feedback from a wider audience as to the utility and convenience of using
> the API.
>
> In addition, we are interested in performance benchmarking in production
> applications.
>
> Ongoing technical constraints
>
> None.
>
>
> Debuggability
>
> Developers can piggyback on existing DevTools support for Promises to help
> with debugging JSPI applications. In particular the existing mechanisms for
> constructing extended stack traces from so-called Promise chains will also
> include stack traces from JSPI applications.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
>
> I'm guessing it will be covered by tests, at least eventually?
>
>
>
>
> Flag name on chrome://flagsenable-experimental-webassembly-stack-switching
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12191=
> owner%3Ame=2
>
> Estimated milestonesOriginTrial desktop last130OriginTrial desktop first
> 122OriginTrial Android last130OriginTrial Android first122OriginTrial
> webView last130OriginTrial webView first122
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5674874568704000
>
> Links to previous Intent discussionsIntent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_
> guVq26rcNM1nWY442Y5Ng%40mail.gmail.com Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/
> CAE65UWD8e57Bd5x3nr63M3QcdPo6TKom%2BVZT%3DvO2Uo4x6th_kA%40mail.gmail.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
>

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAE65UWDSWF%2BDQ2pCc-F3C%3DOodohzdAo5JMw0cDfaTasbTi9EhQ%40mail.gmail.com.

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

['Issack John' via blink-dev]

Contact emails
issackj...@microsoft.com, 
seth.bren...@microsoft.com

Explainer
https://github.com/WICG/crash-reporting/issues/12

Specification
https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing

Summary

This feature captures the JS call stack when a web page becomes unresponsive 
due to JavaScript code running an infinite loop or other very long computation. 
This helps developers to identify the cause of the unresponsiveness and fix it 
more easily. The JS call stack is included in the crash reporting API when the 
reason is unresponsive.


Blink component
Blink>ReportingObserver

Motivation

When a web page becomes unresponsive, it's often because of JavaScript code 
which is busy running an infinite loop or other very long computation. When a 
developer receives a report from the crash reporting API, and the reason is 
unresponsive, it would be very helpful to include the JS call stack from when 
the page was deemed unresponsive. This would let the website developer more 
easily find the find and fix the problem. What happens instead? The page 
reports that it was terminated due to being unresponsive, but the developer of 
the page has no further information about how to fix the problem.


Initial public proposal
https://bugs.chromium.org/p/chromium/issues/detail?id=1445539

TAG review
None

TAG review status
Pending

Risks


Interoperability and Compatibility

None


Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Is this feature fully tested by 
web-platform-tests?
No

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1445539

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4731248572628992

This intent message was generated by Chrome Platform 
Status.

-- 
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.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com.

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

[Victor Tan]

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 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 shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>   
>
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>> Rick
>>
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> To be clarify,  currently David is not working on the standardizing ALPS 
>>> feature.  
>>>
>>>
>>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>>
 Hi Erik,
 We are actively working on it, but we need to put more efforts to 
 standardization. 
 In the last serval IETF, David is the only person is talking about the 
 ALPS feature.  We'd glad to combine more efforts to move it forward to 
 standardization.

 Bests,
 Victor 

 On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:

> Is the ALPS draft being actively worked on?
>
>  
>
> Various teams at Microsoft that own web sites leveraging client hints 
> have expressed interest in using it, but the lack of a finalized standard 
> has significantly slowed conversations with the teams that own the server 
> code that would need to add support first.
>
>  
>
> Are you looking for help in moving standardization forward?
>
>  
>
> *From:* Yoav Weiss (@Shopify)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.org>; David Benjamin ; Mike 
> Taylor 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> Is the old code point defined somewhere? Would it be possible to add 
> such a definition to one of the I-Ds? Or is this something that's not 
> traditionally defined in IETF drafts?
>
>  
>
> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  
> wrote:
>
> Currently, It's on the code: 
> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
>
> Once we standardize the ALPS RFC draft, we can finalize the value.  
> Hope this helps. 
>
> On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson 
> wrote:
>
> Thanks for clarifying. Last question: where in the specifications is 
> the new 17613 code point documented?
>
>  
>
> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor  
> wrote:
>
> In our OWNERS meeting this week, there was some confusion on what's 
> being proposed here (which is understandable, this isn't quite a typical 
> intent for web exposed feature). Here's a summary of what we're trying to 
> accomplish:
>
> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in 
> M96, which relies on the TLS ALPS protocol extension.
> 2) There are 2 

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

[Philip Jägenstedt]

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
>>
>> Specificationhttps://github.com/w3c/csswg-drafts/issues/2632#
>> issuecomment-438851770
>>
>>
>> Is this actually defined in the spec? Should the spec be more explicit
>> about it?
>>
>
> There was certainly some disagreement about that, but whatwg/html#9425
>  makes it much more explicit.
>

This PR is now ready to land together with the tests via
https://chromium-review.googlesource.com/c/chromium/src/+/3910374 when this
intent is approved.

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfXEf07cEhxmMnOtxWiYf%3D4r1nrHbj4XcsuOPZUs-KrVw%40mail.gmail.com.

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

[Daniel Bratell]

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,

"crossOrigin=true" is just a typo. "crossOrigin" was the original
naming convention for "crossOriginExposed". It was renamed during
code review, but I forgot to update the I2S wording to match that.

We chose to not go with Permissions-Policy for a few reasons.
First is that for fenced frames created through something like
Protected Audience, they have a fixed list of permissions that
must be enabled for the frame to load, so refactoring that to
support one permissions policy that can be either enabled or
enabled would be a lot of effort. Doing that would also allow 1
bit of information to leak from the embedder to the fenced frame,
which is the whole reason we locked down permissions policies in
the first place. We also didn't want the embedder to have any
control over how this header is set (such as having an embedder
opt in on the frame's behalf), and since permissions policies are
based on inheritance, that was something we needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5
mike...@chromium.org wrote:

Hi Liam,

On 1/16/24 3:49 PM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org


Explainer(s)

https://github.com/WICG/turtledove/pull/904



Spec(s)

https://github.com/WICG/fenced-frame/pull/133



Summary

As part of the Privacy Sandbox experiment, we introduced a
way for beacons to be sent automatically if a top-level
navigation is initiated from within an ad frame

.
At the time, we restricted this feature to frames and
subframes that were same-origin to the root ad frame.
However, there is a use case that this is not able to
handle. With third-party ad serving (3PAS), the actual
contents of the ad (including links/click handlers) are
loaded in a cross-origin subframe. Because it is
cross-origin, the frame does not get access to the automatic
beacon API, and therefore is not able to report a top-level
navigation when a user clicks on the ad.


A cross-origin subframe can now opt in to sending automatic
beacons by setting a new response header:
"Allow-Fenced-Frame-Automatic-Beacons". The cross-origin
frame still cannot set automatic beacon data; instead, the
main ad frame will set the automatic beacon data, but opt in
to having the data be used for cross-origin automatic
beacons using a new "crossOrigin=true" parameter. When these
2 criteria are met, the cross-origin subframe will send an
automatic beacon when a top-level navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed"
boolean defined in the spec? Or just a typo?

Another question: is there any reason you chose to create a
new HTTP header, rather than use something like
Permissions-Policy? (Maybe that's not supported for fenced
frames?)



This feature will also fix a separate issue

brought
up externally and allow for ad components to opt into
sending automatic beacons without needing to invoke
setReportEventDataForAutomaticBeacons(); they instead will
just need to supply the
"Allow-Fenced-Frame-Automatic-Beacons" response header. This
will not remove the existing way for ad components to opt
into sending beacons.


Blink component

Blink>FencedFrames




TAG reviews and status

Fenced frames existing TAG review appended with these spec
changes https://github.com/w3ctag/design-reviews/issues/838#




Link to Origin Trial feedback summary

No Origin Trial performed


Is this feature supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for
these feature changes.


Risks


Compatibility

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

[Yoav Weiss (@Shopify)]

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 downsides to this. Our blink process is generally to
> block shipping on the existence of some specification for everything
> necessary for a compatible implementation in a forum that ensures IP
> protection. While this isn't typically an adoption barrier for many
> companies, I know it has been in the past for some (including Microsoft).
> This doesn't mean we have to block on getting consensus in the "right"
> standards venue, we can just do a monkey-patch spec in a venue like the
> WICG, or an unlanded PR in a formal WG where the PR counts as an IP
> contribution. Then we can ship it as an "incubation" while doing the
> standards maturation work in parallel. Erik, can you comment on the extent
> to which such incubation spec work would help with Microsoft adoption?
>
> Victor, is there any chance you can throw something together quickly (spec
> PR or monkey-patch) that would cover the gaps in what's necessary for
> compatible implementations? This particular delta seems very tiny and
> straightforward to me, so I was originally thinking I'd just approve it.
> But in principle I don't think we should be continuing to approve changes
> to APIs which we realize are struggling with adoption due to the standards
> work not quite being up to our I2S bar.
>

+1 to defining these codepoints somewhere. Where are such codepoints
typically defined? I'd have assumed they'd go into one of the relevant
I-Ds..


>
> Erik, thank you for your offer of help on the standardization front! It
> definitely sounds to me like we should be pushing on the full standards
> effort in parallel to this specific intent. Having Microsoft and Google
> work together on that would hopefully be able to accelerate it.
>
> Rick
>
>
> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> To be clarify,  currently David is not working on the standardizing ALPS
>> feature.
>>
>>
>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>
>>> Hi Erik,
>>> We are actively working on it, but we need to put more efforts to
>>> standardization.
>>> In the last serval IETF, David is the only person is talking about the
>>> ALPS feature.  We'd glad to combine more efforts to move it forward to
>>> standardization.
>>>
>>> Bests,
>>> Victor
>>>
>>> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>>>
 Is the ALPS draft being actively worked on?



 Various teams at Microsoft that own web sites leveraging client hints
 have expressed interest in using it, but the lack of a finalized standard
 has significantly slowed conversations with the teams that own the server
 code that would need to add support first.



 Are you looking for help in moving standardization forward?



 *From:* Yoav Weiss (@Shopify) 
 *Sent:* Monday, January 22, 2024 7:39 AM
 *To:* Victor Tan 
 *Cc:* blink-dev ; Chris Harrelson <
 chri...@chromium.org>; David Benjamin ; Mike
 Taylor 
 *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point



 Is the old code point defined somewhere? Would it be possible to add
 such a definition to one of the I-Ds? Or is this something that's not
 traditionally defined in IETF drafts?



 On Mon, Jan 22, 2024 at 4:03 PM Victor Tan 
 wrote:

 Currently, It's on the code:
 https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247

 Once we standardize the ALPS RFC draft, we can finalize the value.
 Hope this helps.

 On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson
 wrote:

 Thanks for clarifying. Last question: where in the specifications is
 the new 17613 code point documented?



 On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor 
 wrote:

 In our OWNERS meeting this week, there was some confusion on what's
 being proposed here (which is understandable, this isn't quite a typical
 intent for web exposed feature). Here's a summary of what we're trying to
 accomplish:

 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in
 M96, which relies on the TLS ALPS protocol extension.
 2) There are 2 parts to this: the client being able to understand
 ALPS/ACCEPT_CH (and in return do something useful), and the server being
 able to send it.
 3) Because of a (long fixed) bug present in Chromium's implementation,
 it's risky for a server to send too much data via ACCEPT_CH, so it's
 usefulness is potentially limited.
 4) In order to guarantee that older clients 

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

[Yoav Weiss (@Shopify)]

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 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 getHTML()? Can we redirect users
> to it already?
>
> /Daniel
> On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
>
> I guess a theoretical risk is that someone feature-checks for
> HTMLTemplateElement.shadowRootMode and then assumes the existence of
> getInnerHTML() based on that check. But given the lack of usage in the top
> sites I agree that this seems to not be an issue in practice.
>
> I saw that there's a support email listed at https://www.heap.io/auryc.
> Maybe worth a ping?
>
> -- Dan
>
> On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:
>
>> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin  wrote:
>>
>>> Yeah, I think the risk is low here.

>>>
>> Great, thanks!
>>
>>
>>> FWIW, I couldn't find any relevant github or contact info for this
>>> library but if you had better luck finding contact information, we might as
>>> well file an issue or send an email.
>>>
>>
>> I also tried to find it, but failed. It appears to be closed source.
>>
>> Thanks,
>> Mason
>>
>>
>>
>>>
 Thanks,
 Mason




 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?

 None


 Debuggability

 None


 Is this feature fully tested by web-platform-tests
 
 ?No

 Flag name on chrome://flagsNone

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/1519972

 Estimated milestones

 No milestones specified


 Link to entry on the Chrome Platform Statushttps://chromestatus.com/
 feature/5081733588582400

 This intent message was generated by me, manually, because of this bug
 .

 --
 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.com/a/
 chromium.org/d/msgid/blink-dev/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
 ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.com
 
 .

 --
> 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.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org
> 
> .
>
> --
> 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.com/a/chromium.org/d/msgid/blink-dev/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.com
> 
> .
>

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKmPxizyAqwxuz5w-HwaULCX6x9yQv7sciwR7Yq2Rbeuw%40mail.gmail.com.

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

[Daniel Bratell]

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 getHTML()? Can we redirect users 
to it already?


/Daniel

On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
I guess a theoretical risk is that someone feature-checks for 
HTMLTemplateElement.shadowRootMode and then assumes the existence of 
getInnerHTML() based on that check. But given the lack of usage in the 
top sites I agree that this seems to not be an issue in practice.


I saw that there's a support email listed at 
https://www.heap.io/auryc. Maybe worth a ping?


-- Dan

On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:

On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
wrote:

Yeah, I think the risk is low here.


Great, thanks!

FWIW, I couldn't find any relevant github or contact info for
this library but if you had better luck finding contact
information, we might as well file an issue or send an email.


I also tried to find it, but failed. It appears to be closed source.

Thanks,
Mason


Thanks,
Mason



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

WebView application risks

Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high
risk for Android WebView-based applications?

None



Debuggability

None



Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/1519972

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform
Statushttps://chromestatus.com/feature/5081733588582400


This intent message was generated by me, manually,
because of this bug

.

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.com

.

--
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.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org 
.


--
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.com/a/chromium.org/d/msgid/blink-dev/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.com.

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

[Rick Byers]

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 shipping on the existence of some specification for everything
necessary for a compatible implementation in a forum that ensures IP
protection. While this isn't typically an adoption barrier for many
companies, I know it has been in the past for some (including Microsoft).
This doesn't mean we have to block on getting consensus in the "right"
standards venue, we can just do a monkey-patch spec in a venue like the
WICG, or an unlanded PR in a formal WG where the PR counts as an IP
contribution. Then we can ship it as an "incubation" while doing the
standards maturation work in parallel. Erik, can you comment on the extent
to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec
PR or monkey-patch) that would cover the gaps in what's necessary for
compatible implementations? This particular delta seems very tiny and
straightforward to me, so I was originally thinking I'd just approve it.
But in principle I don't think we should be continuing to approve changes
to APIs which we realize are struggling with adoption due to the standards
work not quite being up to our I2S bar.

Erik, thank you for your offer of help on the standardization front! It
definitely sounds to me like we should be pushing on the full standards
effort in parallel to this specific intent. Having Microsoft and Google
work together on that would hopefully be able to accelerate it.

Rick


On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
blink-dev@chromium.org> wrote:

> To be clarify,  currently David is not working on the standardizing ALPS
> feature.
>
>
> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>
>> Hi Erik,
>> We are actively working on it, but we need to put more efforts to
>> standardization.
>> In the last serval IETF, David is the only person is talking about the
>> ALPS feature.  We'd glad to combine more efforts to move it forward to
>> standardization.
>>
>> Bests,
>> Victor
>>
>> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>>
>>> Is the ALPS draft being actively worked on?
>>>
>>>
>>>
>>> Various teams at Microsoft that own web sites leveraging client hints
>>> have expressed interest in using it, but the lack of a finalized standard
>>> has significantly slowed conversations with the teams that own the server
>>> code that would need to add support first.
>>>
>>>
>>>
>>> Are you looking for help in moving standardization forward?
>>>
>>>
>>>
>>> *From:* Yoav Weiss (@Shopify) 
>>> *Sent:* Monday, January 22, 2024 7:39 AM
>>> *To:* Victor Tan 
>>> *Cc:* blink-dev ; Chris Harrelson <
>>> chri...@chromium.org>; David Benjamin ; Mike
>>> Taylor 
>>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>>
>>>
>>>
>>> Is the old code point defined somewhere? Would it be possible to add
>>> such a definition to one of the I-Ds? Or is this something that's not
>>> traditionally defined in IETF drafts?
>>>
>>>
>>>
>>> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  wrote:
>>>
>>> Currently, It's on the code:
>>> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
>>>
>>> Once we standardize the ALPS RFC draft, we can finalize the value.  Hope
>>> this helps.
>>>
>>> On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote:
>>>
>>> Thanks for clarifying. Last question: where in the specifications is the
>>> new 17613 code point documented?
>>>
>>>
>>>
>>> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor 
>>> wrote:
>>>
>>> In our OWNERS meeting this week, there was some confusion on what's
>>> being proposed here (which is understandable, this isn't quite a typical
>>> intent for web exposed feature). Here's a summary of what we're trying to
>>> accomplish:
>>>
>>> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in
>>> M96, which relies on the TLS ALPS protocol extension.
>>> 2) There are 2 parts to this: the client being able to understand
>>> ALPS/ACCEPT_CH (and in return do something useful), and the server being
>>> able to send it.
>>> 3) Because of a (long fixed) bug present in Chromium's implementation,
>>> it's risky for a server to send too much data via ACCEPT_CH, so it's
>>> usefulness is potentially limited.
>>> 4) In order to guarantee that older clients don't have this bug, we
>>> propose to rev the version (aka, code point) at the protocol layer. This
>>> way, if a server sends the new code point and the client understands it, it
>>> can send a larger payload without triggering the bug (which may result in
>>> sad things like a connection being refused).
>>> 5) This is sort of web observable, but right now 

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

[Rick Byers]

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 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  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,
>>Rick
>>
>>
>>
>> On Fri, Jan 5, 2024 at 1:05 PM 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
>>> 
>>>
>>>
>>> Specification
>>>
>>> Ad slot size in real-time bidding signals fetch:
>>> https://github.com/WICG/turtledove/pull/954
>>>
>>> Update more interest group fields:
>>> https://github.com/WICG/turtledove/pull/907
>>> https://github.com/WICG/turtledove/pull/953
>>>
>>>
>>> Summary
>>>
>>> Ad slot size in real-time bidding signals fetch:
>>>
>>> Protected Audience ad selection auctions allow buyers to fetch real-time
>>> signals from their key-value server.  Besides being used for calculating
>>> bid prices, these signals can also be used for prioritizing and filtering
>>> potential ad candidates.  The more ad candidate filtration and
>>> prioritization that we can enable, the more performant the auction is (e.g.
>>> less browser resource utilization) and the higher the quality of the chosen
>>> ad candidates is.  This feature extends the signals about the page where
>>> the ad will be displayed from just its domain name, to also include the
>>> size of the ad slots on the page, which is a very useful signal for
>>> filtering out ads that cannot be rendered in that slot size.
>>>
>>> Allow updating interest group’s userBiddingSignals and executionMode:
>>>
>>> Protected Audience has always supported updating interest group fields,
>>> but for historical reasons did not support updating the interest group
>>> field named userBiddingSignals, and for no obvious reason did not support
>>> updating executionMode. This change is a small extension to Protected
>>> Audience interest group updating to support updating these fields, making
>>> the API more useful by being able to update/refresh the fields with more up
>>> to date information.
>>>
>>>
>>> Blink component
>>>
>>> Blink>InterestGroups
>>> 
>>>
>>>
>>> TAG review
>>>
>>> The parent proposal, Protected Audience, is still pending:
>>> https://github.com/w3ctag/design-reviews/issues/723
>>>
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> These are both optional new features so we do not expect them to cause
>>> compatibility breakage.
>>>
>>>
>>> Gecko & WebKit: No signal on parent proposal, Protected Audience.
>>> Asked in the Mozilla forum here
>>> , and in the
>>> Webkit forum here
>>> .
>>>
>>>
>>> Web developers:
>>>
>>> Ad slot size in real-time bidding signals fetch: Interest from multiple
>>> adtechs here .
>>>
>>> Update more interest group fields: Interest from adtech here
>>> .
>>>
>>>
>>> Debuggability
>>>
>>> Ad slot size in real-time bidding signals fetch: The extra
>>> runAdAuction() and joinAdInterestGroup() parameters should be visible in
>>> DevTools, as should the real-time bidding signal fetches in the DevTools
>>> network panel.
>>>
>>> Update more interest group fields: The updates should be visible in
>>> DevTools’ Application Storage Interest Group section.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?
>>>
>>> It will be supported on all platforms that support Protected Audience,
>>> so all but WebView.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> We plan to land web-platform-tests for both features shortly.  Some
>>> have already landed
>>> 

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

[Rick Byers]

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 experiment.

On Wed, Jan 24, 2024 at 6:09 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> 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/
> proposals/js-promise-integration/Overview.md
>
> Specificationhttps://github.com/WebAssembly/js-promise-
> integration/blob/main/proposals/js-promise-integration/Overview.md
>
> Summary
>
> Stack Switching denotes a technology that allows programs to suspend and
> resume computation. This is an active area that is part of the WebAssembly
> standards track. See https://github.com/WebAssembly/stack-switching and
> https://github.com/WebAssembly/meetings/tree/main/stack. This particular
> feature refers to the integration between JavaScript Promises and stack
> switching. This is described in more detail in https://docs.google.com/
> document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#
>
>
> Blink componentBlink>JavaScript>WebAssembly
> 
>
> Search tagsstack switching
> , Promise
> , JSPI
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> This spec is backed by a standardization effort. We do not plan to ship
> the JSPI until it has been standardized by the W3C Wasm WG. However, post
> standardization, we will depend on all browsers implementing the standard.
>
>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627)
> Mozilla have started their own imlementation
>
>
> That doesn't count as a positive signal. Please file for official signals
>  (but that is not blocking for this OT).
>
>
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Goals for experimentation
>
> This specification is getting close to finalization. We would like
> feedback from a wider audience as to the utility and convenience of using
> the API.
>
> In addition, we are interested in performance benchmarking in production
> applications.
>
> Ongoing technical constraints
>
> None.
>
>
> Debuggability
>
> Developers can piggyback on existing DevTools support for Promises to help
> with debugging JSPI applications. In particular the existing mechanisms for
> constructing extended stack traces from so-called Promise chains will also
> include stack traces from JSPI applications.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
>
> I'm guessing it will be covered by tests, at least eventually?
>
>
>
>
> Flag name on chrome://flagsenable-experimental-webassembly-stack-switching
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12191=
> owner%3Ame=2
>
> Estimated milestonesOriginTrial desktop last130OriginTrial desktop first
> 122OriginTrial Android last130OriginTrial Android first122OriginTrial
> webView last130OriginTrial webView first122
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5674874568704000
>
> Links to previous Intent discussionsIntent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_
> guVq26rcNM1nWY442Y5Ng%40mail.gmail.com Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/
> CAE65UWD8e57Bd5x3nr63M3QcdPo6TKom%2BVZT%3DvO2Uo4x6th_kA%40mail.gmail.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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
> 

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

[Paul Jensen]

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 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,
>Rick
>
>
>
> On Fri, Jan 5, 2024 at 1:05 PM 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
>> 
>>
>>
>> Specification
>>
>> Ad slot size in real-time bidding signals fetch:
>> https://github.com/WICG/turtledove/pull/954
>>
>> Update more interest group fields:
>> https://github.com/WICG/turtledove/pull/907
>> https://github.com/WICG/turtledove/pull/953
>>
>>
>> Summary
>>
>> Ad slot size in real-time bidding signals fetch:
>>
>> Protected Audience ad selection auctions allow buyers to fetch real-time
>> signals from their key-value server.  Besides being used for calculating
>> bid prices, these signals can also be used for prioritizing and filtering
>> potential ad candidates.  The more ad candidate filtration and
>> prioritization that we can enable, the more performant the auction is (e.g.
>> less browser resource utilization) and the higher the quality of the chosen
>> ad candidates is.  This feature extends the signals about the page where
>> the ad will be displayed from just its domain name, to also include the
>> size of the ad slots on the page, which is a very useful signal for
>> filtering out ads that cannot be rendered in that slot size.
>>
>> Allow updating interest group’s userBiddingSignals and executionMode:
>>
>> Protected Audience has always supported updating interest group fields,
>> but for historical reasons did not support updating the interest group
>> field named userBiddingSignals, and for no obvious reason did not support
>> updating executionMode. This change is a small extension to Protected
>> Audience interest group updating to support updating these fields, making
>> the API more useful by being able to update/refresh the fields with more up
>> to date information.
>>
>>
>> Blink component
>>
>> Blink>InterestGroups
>> 
>>
>>
>> TAG review
>>
>> The parent proposal, Protected Audience, is still pending:
>> https://github.com/w3ctag/design-reviews/issues/723
>>
>>
>> TAG review status
>>
>> Pending
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> These are both optional new features so we do not expect them to cause
>> compatibility breakage.
>>
>>
>> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
>> in the Mozilla forum here
>> , and in the
>> Webkit forum here
>> .
>>
>>
>> Web developers:
>>
>> Ad slot size in real-time bidding signals fetch: Interest from multiple
>> adtechs here .
>>
>> Update more interest group fields: Interest from adtech here
>> .
>>
>>
>> Debuggability
>>
>> Ad slot size in real-time bidding signals fetch: The extra
>> runAdAuction() and joinAdInterestGroup() parameters should be visible in
>> DevTools, as should the real-time bidding signal fetches in the DevTools
>> network panel.
>>
>> Update more interest group fields: The updates should be visible in
>> DevTools’ Application Storage Interest Group section.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> It will be supported on all platforms that support Protected Audience, so
>> all but WebView.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> We plan to land web-platform-tests for both features shortly.  Some have
>> already landed
>> 
>> .
>>
>>
>> Flag name on chrome://flags
>>
>> None
>>
>>
>> Finch feature name
>>
>> EnableIFrameAdAuctionHeaders, EnableUpdatingExecutionModeToFrozenContext,
>> EnableUpdatingUserBiddingSignals
>>
>>

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

[Yoav Weiss (@Shopify)]

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 <
> admin+dome...@cr-status.appspotmail.com> wrote:
>
>> 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, e.g. a potential
>> breaking change? Assuming not, LGTM2.
>>
>> --
>> 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.com/a/chromium.org/d/msgid/blink-dev/e18baf060fb03dd3%40google.com
>> 
>> .
>>
> --
> 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.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZU6mo7A42gsmBa97UUn3CJG_iuQR9HueVyUOmgdiXMqQ%40mail.gmail.com
> 
> .
>

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLQNfNP%2BCk7fX%2B%3DweSb5zTrF8DsDd237S_qtC_CYV3o-Q%40mail.gmail.com.

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

[Noam Rosenthal]

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 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, e.g. a potential
> breaking change? Assuming not, LGTM2.
>
> --
> 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.com/a/chromium.org/d/msgid/blink-dev/e18baf060fb03dd3%40google.com
> 
> .
>

-- 
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.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZU6mo7A42gsmBa97UUn3CJG_iuQR9HueVyUOmgdiXMqQ%40mail.gmail.com.

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

[domenic via Chromestatus]

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 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.com/a/chromium.org/d/msgid/blink-dev/e18baf060fb03dd3%40google.com.

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

[Mike Taylor]

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:



Regarding the spec, I see that it's monkeypatching WebIDL, DOM
and HTML. This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?


Was planning to upstream the monkey-patches once we have formal
positive signals from Gecko/WebKit.

--
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.com/a/chromium.org/d/msgid/blink-dev/1fe0c37e-d02c-474e-824f-498d7866c598n%40chromium.org 
.


--
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.com/a/chromium.org/d/msgid/blink-dev/63bf8b4c-c76f-4061-9f5b-dfd639bb2743%40chromium.org.

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

[Mike Taylor]

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

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled


Summary

There was an attempt in 2014 
 
to deprecate and remove the HTMLVideoElement-specific Prefixed 
Fullscreen APIs. This meant removing the following APIs from 
HTMLVideoElement:


readonly attribute boolean webkitSupportsFullscreen;
readonly attribute boolean webkitDisplayingFullscreen;
void webkitEnterFullscreen();
void webkitExitFullscreen();
// Note the different capitalization of the "S" in FullScreen.
void webkitEnterFullScreen();
void webkitExitFullScreen();

The overall usage of these APIs is low, and has trended downwards over 
time. Here are the latest usage numbers, as a % of total page loads:


PrefixedVideoSupportsFullscreen: 0.025%
PrefixedVideoDisplayingFullscreen: 0.082%
PrefixedVideoEnterFullscreen: 0.001%
PrefixedVideoExitFullscreen: 0.010%
PrefixedVideoEnterFullScreen: 0.001%
PrefixedVideoExitFullScreen: 0.000%


There has been an unfortunate uptick in the past 2 years for the two 
following APIs, which means that it's best to remove them now, before 
they see a wider adoption. These numbers might be going up because the 
prefixed APIs are also present on iOS.


https://chromestatus.com/metrics/feature/timeline/popularity/166
https://chromestatus.com/metrics/feature/timeline/popularity/167

There is an alternative set of APIs supported by all browsers that web 
authors can use.


The full history of the removal attempt is here: crbug.com/ 
346236



Goals for experimentation

The primary goal of the deprecation trial is to reduce the amount of 
broken user-visible experiences as the prefixed fullscreen APIs are 
removed, and to give time to web authors to transition to the modern 
API (which has been available for 5 years).



The un-prefixed fullscreen APIs have been available since Chrome M71.


Experiment timeline

TBD, with a proposed 3 months duration


Blink component

Blink>Fullscreen
Blink>Media>Video



TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

Web Compatibility:

Removing non-standard APIs should overall help web
compatibility, and encourage web authors to use the unprefixed
APIs. Some experiences might be broken by this change, thus
justifying this deprecation trial. The API has been deprecated
for a significant amount of time however, and usage has gone down.

This would only be an issue for websites that *only* support
the prefixed APIs.


Interoperability:


All browsers have shipped the new APIs, most of them using an 
unprefixed version (Safari on iOS being the only remaining 
prefixed-only API). See also 
https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility



Gecko:


WebKit:


Web developers:


Other signals:


Activation

Impact on the Ads ecosystem:

N/A



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?


Potentially. The deprecation trial should give a heads up and 
appropriate time for apps to switch over to the unprefixed APIs.





Ongoing technical constraints

None



Debuggability

N/A


Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes - the prefixed API will be removed across all platforms.


Is this feature fully tested by web-platform-tests

?

Yes

WPTs testing the prefixes are removed: 
https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html


WPTs testing the new API: 
https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api




Flag name on chrome://flags

None


Finch feature name

PrefixedVideoFullscreen


Non-finch justification

None


Requires code in //chrome?

False


Launch bug

None


Estimated milestones

DevTrial on desktop



123


DevTrial on Android



123



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5259513871466496

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

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

[Mike Taylor]

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 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 in working to
preserve personalized / authenticated embeds (and so the rich
composition of web pages) where we can ensure it doesn't conflict
with our privacy goals around clear user transparency and control
over sharing of information (fenced frames

being the most obvious example). We know that avoiding popups and
redirects helps reduce drop-off in any authentication or commerce
flow, and combined with Stripe's public statement of support, I'm
convinced this is a valuable capability.

Everything else looks great to me, so LGTM1

On Tue, Jan 23, 2024 at 10:23 AM Stephen McGruer
 wrote:

Fyi; I've retargeted this launch to M123 since it seems clear
it won't get the necessary Blink approvals in time for M122
(which has already branched).

On Wednesday, January 17, 2024 at 11:07:56 AM UTC-5 Stephen
McGruer wrote:

Sounds great:

https://github.com/WebKit/standards-positions/issues/304

https://github.com/mozilla/standards-positions/issues/964


Will update if we get any reply :)

On Wed, 17 Jan 2024 at 10:25, Mike Taylor
 wrote:

I think erring on the side of requesting a signal here
is a good idea. :)

On 1/17/24 8:33 AM, Stephen Mcgruer wrote:

API owners: It wasn't clear to me if I should still
be formally requesting signals from WebKit and Gecko
in the case of a change to an API (WebAuthn) where
the change has been ratified + landed by the
associated Working Group. The change is in some ways
'minor', but in other ways it is significant new
behavior (allowing use of part of the API in
cross-origin iframes, where it wasn't allowed before)
and so perhaps requesting signals is warranted? Let
me know please :D

On Wed, 17 Jan 2024 at 08:31, Stephen Mcgruer
 wrote:


Contact emails

smcgr...@chromium.org


Explainer

None


Specification


https://w3c.github.io/webauthn/#publickey-credentials-create-feature




Summary

This feature allows web developers to create
WebAuthn[0] credentials (that is, "publickey"
credentials, aka passkeys) in cross-origin
iframes. Two conditions are required for this new
ability: 1. The iframe has a
publickey-credentials-create-feature permission
policy. 2. The iframe has transient user
activation. This will allow developers to create
passkeys in embedded scenarios, such as after an
identity step-up flow where the Relying Party is
providing a federated identity experience. [0]:
https://w3c.github.io/webauthn/



Blink component

Blink>WebAuthentication




TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

There is only minor interoperability risk if
other browsers do not adopt this change. In a
browser that does not support credential creation
inside a cross-origin iframe, attempting to call
navigator.credentials.create results in an
asynchronous-but-immediate error message
indicating that creation cannot happen. This
means that a developer can create a fallback flow

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

[Yoav Weiss (@Shopify)]

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/
proposals/js-promise-integration/Overview.md

Specificationhttps://github.com/WebAssembly/js-promise-
integration/blob/main/proposals/js-promise-integration/Overview.md

Summary

Stack Switching denotes a technology that allows programs to suspend and 
resume computation. This is an active area that is part of the WebAssembly 
standards track. See https://github.com/WebAssembly/stack-switching and 
https://github.com/WebAssembly/meetings/tree/main/stack. This particular 
feature refers to the integration between JavaScript Promises and stack 
switching. This is described in more detail in https://docs.google.com/
document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#


Blink componentBlink>JavaScript>WebAssembly 


Search tagsstack switching 
, Promise 
, JSPI 


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809

TAG review statusPending

Risks


Interoperability and Compatibility

This spec is backed by a standardization effort. We do not plan to ship the 
JSPI until it has been standardized by the W3C Wasm WG. However, post 
standardization, we will depend on all browsers implementing the standard.


*Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627) 
Mozilla have started their own imlementation


That doesn't count as a positive signal. Please file for official signals 
 (but that is not blocking for this OT).
 


*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that 
it has potentially high risk for Android WebView-based applications?



Goals for experimentation

This specification is getting close to finalization. We would like feedback 
from a wider audience as to the utility and convenience of using the API.

In addition, we are interested in performance benchmarking in production 
applications.

Ongoing technical constraints

None.


Debuggability

Developers can piggyback on existing DevTools support for Promises to help 
with debugging JSPI applications. In particular the existing mechanisms for 
constructing extended stack traces from so-called Promise chains will also 
include stack traces from JSPI applications.


Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests 

?No


I'm guessing it will be covered by tests, at least eventually?
 



Flag name on chrome://flagsenable-experimental-webassembly-stack-switching

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12191=
owner%3Ame=2

Estimated milestonesOriginTrial desktop last130OriginTrial desktop 
first122OriginTrial 
Android last130OriginTrial Android first122OriginTrial webView 
last130OriginTrial 
webView first122

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5674874568704000

Links to previous Intent discussionsIntent to prototype: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_
guVq26rcNM1nWY442Y5Ng%40mail.gmail.com Intent to Experiment: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CAE65UWD8e57Bd5x3nr63M3QcdPo6T
Kom%2BVZT%3DvO2Uo4x6th_kA%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

-- 
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.com/a/chromium.org/d/msgid/blink-dev/a6f6bbfe-498e-4812-9773-f19706db4547n%40chromium.org.

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

[Yoav Weiss (@Shopify)]

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 
> convention for "crossOriginExposed". It was renamed during code review, but 
> I forgot to update the I2S wording to match that.
>
> We chose to not go with Permissions-Policy for a few reasons. First is 
> that for fenced frames created through something like Protected Audience, 
> they have a fixed list of permissions that must be enabled for the frame to 
> load, so refactoring that to support one permissions policy that can be 
> either enabled or enabled would be a lot of effort. Doing that would also 
> allow 1 bit of information to leak from the embedder to the fenced frame, 
> which is the whole reason we locked down permissions policies in the first 
> place. We also didn't want the embedder to have any control over how this 
> header is set (such as having an embedder opt in on the frame's behalf), 
> and since permissions policies are based on inheritance, that was something 
> we needed to avoid. 
> On Friday, January 19, 2024 at 3:43:44 PM UTC-5 mike...@chromium.org 
> wrote:
>
>> Hi Liam,
>> On 1/16/24 3:49 PM, 'Liam Brady' via blink-dev wrote:
>>
>> Contact emails
>>
>> lbr...@google.com, shiva...@chromium.org, jka...@chromium.org
>>
>> Explainer(s)
>>
>> https://github.com/WICG/turtledove/pull/904
>>
>> Spec(s)
>>
>> https://github.com/WICG/fenced-frame/pull/133
>>
>> Summary
>>
>> As part of the Privacy Sandbox experiment, we introduced a way for 
>> beacons to be sent automatically if a top-level navigation is initiated 
>> from within an ad frame 
>> .
>>  
>> At the time, we restricted this feature to frames and subframes that were 
>> same-origin to the root ad frame. However, there is a use case that this is 
>> not able to handle. With third-party ad serving (3PAS), the actual contents 
>> of the ad (including links/click handlers) are loaded in a cross-origin 
>> subframe. Because it is cross-origin, the frame does not get access to the 
>> automatic beacon API, and therefore is not able to report a top-level 
>> navigation when a user clicks on the ad.
>>
>> A cross-origin subframe can now opt in to sending automatic beacons by 
>> setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". The 
>> cross-origin frame still cannot set automatic beacon data; instead, the 
>> main ad frame will set the automatic beacon data, but opt in to having the 
>> data be used for cross-origin automatic beacons using a new 
>> "crossOrigin=true" parameter. When these 2 criteria are met, the 
>> cross-origin subframe will send an automatic beacon when a top-level 
>> navigation happens.
>>
>> Is "crossOrigin=true" different than the "crossOriginExposed" boolean 
>> defined in the spec? Or just a typo?
>>
>> Another question: is there any reason you chose to create a new HTTP 
>> header, rather than use something like Permissions-Policy? (Maybe that's 
>> not supported for fenced frames?)
>>
>>
>> This feature will also fix a separate issue 
>>  
>> brought up externally and allow for ad components to opt into sending 
>> automatic beacons without needing to invoke 
>> setReportEventDataForAutomaticBeacons(); they instead will just need to 
>> supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. This 
>> will not remove the existing way for ad components to opt into sending 
>> beacons.
>>
>> Blink component
>>
>> Blink>FencedFrames 
>> 
>>
>> TAG reviews and status
>>
>> Fenced frames existing TAG review appended with these spec changes 
>> https://github.com/w3ctag/design-reviews/issues/838# 
>> 
>>
>> Link to Origin Trial feedback summary
>>
>> No Origin Trial performed
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Supported on all the above platforms except Android WebView.
>>
>> Debuggability
>>
>> Additional debugging capabilities are not necessary for these feature 
>> changes.
>>
>> Risks
>>
>> Compatibility
>>
>> This is an added functionality and is backward compatible.
>>
>> Interoperability
>>
>> There are no interoperability risks as no other browsers have decided to 
>> implement these features yet.
>>
>> Is this feature fully tested by web-platform-tests 
>> ?
>>  
>> Link to test suite results from wpt.fyi. 
>>
>> Yes. New automatic beacon tests have been added to test 

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

[Yoav Weiss (@Shopify)]

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 
> engine's preference for embeds being anonymous. In Chromium we've been 
> consistent in working to preserve personalized / authenticated embeds (and 
> so the rich composition of web pages) where we can ensure it doesn't 
> conflict with our privacy goals around clear user transparency and control 
> over sharing of information (fenced frames 
>  
> being the most obvious example). We know that avoiding popups and redirects 
> helps reduce drop-off in any authentication or commerce flow, and combined 
> with Stripe's public statement of support, I'm convinced this is a valuable 
> capability. 
>
> Everything else looks great to me, so LGTM1
>
> On Tue, Jan 23, 2024 at 10:23 AM Stephen McGruer  
> wrote:
>
>> Fyi; I've retargeted this launch to M123 since it seems clear it won't 
>> get the necessary Blink approvals in time for M122 (which has already 
>> branched).
>>
>> On Wednesday, January 17, 2024 at 11:07:56 AM UTC-5 Stephen McGruer wrote:
>>
>>> Sounds great:
>>>
>>> https://github.com/WebKit/standards-positions/issues/304
>>> https://github.com/mozilla/standards-positions/issues/964
>>>
>>> Will update if we get any reply :)
>>>
>>> On Wed, 17 Jan 2024 at 10:25, Mike Taylor  
>>> wrote:
>>>
 I think erring on the side of requesting a signal here is a good idea. 
 :)
 On 1/17/24 8:33 AM, Stephen Mcgruer wrote:

 API owners: It wasn't clear to me if I should still be formally 
 requesting signals from WebKit and Gecko in the case of a change to an API 
 (WebAuthn) where the change has been ratified + landed by the associated 
 Working Group. The change is in some ways 'minor', but in other ways it is 
 significant new behavior (allowing use of part of the API in cross-origin 
 iframes, where it wasn't allowed before) and so perhaps requesting signals 
 is warranted? Let me know please :D

 On Wed, 17 Jan 2024 at 08:31, Stephen Mcgruer  
 wrote:

> Contact emails smcgr...@chromium.org
>
> Explainer None
>
> Specification 
> https://w3c.github.io/webauthn/#publickey-credentials-create-feature
>
> Summary 
>
> This feature allows web developers to create WebAuthn[0] credentials 
> (that is, "publickey" credentials, aka passkeys) in cross-origin iframes. 
> Two conditions are required for this new ability: 1. The iframe has a 
> publickey-credentials-create-feature permission policy. 2. The iframe has 
> transient user activation. This will allow developers to create passkeys 
> in 
> embedded scenarios, such as after an identity step-up flow where the 
> Relying Party is providing a federated identity experience. [0]: 
> https://w3c.github.io/webauthn/
>
> Blink component Blink>WebAuthentication 
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks 
> Interoperability and Compatibility 
>
> There is only minor interoperability risk if other browsers do not 
> adopt this change. In a browser that does not support credential creation 
> inside a cross-origin iframe, attempting to call 
> navigator.credentials.create results in an asynchronous-but-immediate 
> error 
> message indicating that creation cannot happen. This means that a 
> developer 
> can create a fallback flow of: 1. Have some button for the user, e.g. 
> "register passkey", in the iframe 2. When the user clicks it, attempt to 
> create a credential 3. If it fails due to an incompatible browser, 
> instead 
> use the click to open a pop-up window in which one *can* do the 
> registration - a much poorer user flow but one that works.
>
> *Gecko*: No signal
>
> *WebKit*: No signal No formal signal, but note that folks from Apple 
> were against the proposal when discussed in the WebAuthn WG
>
> *Web developers*: Positive developer feedback on 
> https://github.com/w3c/webauthn/issues/1656 (one example - 
> https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). 
> No known negative developer feedback
>
> *Other signals*:
>
> Security 
>
> To avoid malicious iframes from creating credentials (attempting to 
> trick the user in some way), this feature requires both (a) a new 
> permission policy set on the frame, and (b) a user gesture (so the user 
> must click or interact with the iframe in some way).
>
> WebView application risks 
>
> Does this