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

[Philip Jägenstedt]

On Tue, Jan 23, 2024 at 2:31 AM 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.
>

You're probably thinking of these threads:
https://groups.google.com/a/chromium.org/g/blink-dev/c/gIyvMw0n2qw/m/CC7RlhguAgAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/V7q43bgutbo/m/GpJogpw4AgAJ

Checking 20 sites at random and finding no breakage gives us 95% confidence
that the true occurence of broken sites is no more than ~17%. Checking 40
reduces that to ~9%. (Based on
https://sample-size.net/confidence-interval-proportion/.) If the set we're
sampling from is sites that hit a use counter, then it says something about
the real risk of breaking that code path.

Checking 20 like Thomas did seems enough to me, we're starting from a low
risk and just want to know if breakage is common or not. It seems to not be
common even on sites that use the APIs.

-- 
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/CAARdPYd7X6deDxQPywsiGJ3W%3DQPhTuPL8jQaB860SXZB0hxYVQ%40mail.gmail.com.

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

[Philip Jägenstedt]

On Thu, Jan 25, 2024 at 2: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
>

Thanks for sharing! This code falls back to the
standard media.requestFullscreen() API if media.webkitEnterFullscreen isn't
available, so it won't break.

I suspect this order of feature detection could be common because the
video-specific prefixed fullscreen APIs are the very oldest, followed by
the generic prefixed APIs, and the standard APIs came around much, much
later.

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

BigScreen seems to use the standard API if both are present, and screenfull
doesn't deal with the video-specific prefixed APIs at all. So neither of
these ought to explain usage we're seeing via use counters.


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

Yeah, I was very happy to see that ship.

-- 
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/CAARdPYdyE2jpVcmWX4sesARxh9tvz0jOy%2BZBdCyferyVpMSApg%40mail.gmail.com.

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

[Philip Jägenstedt]

I'm also happy to support a plan to deprecate and remove. The use counter
that best represents worst-case user impact at
https://chromestatus.com/metrics/feature/timeline/popularity/170 at
~0.001%. But that's only when fullscreen actually happens (on user
interaction) and it's very hard to say what proportion of sites could
*potentially* hit this code path, especially given the ubiquitous pattern
of trying multiple API names that's been necessary forever with fullscreen,
so that some sites will just fall back to a working API.

What timeline do you have in mind?

On Thu, Jan 25, 2024 at 2:19 AM Domenic Denicola 
wrote:

> 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 

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

[Dave Tapuska]

Yes I was thinking of how the stack trace format was standardized as well.
How do wasm call stacks work with this proposal?

dave.

On Wed, Jan 24, 2024 at 8:27 PM Domenic Denicola 
wrote:

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

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

[Mike Taylor]

LGTM2

On 1/24/24 4:10 PM, Rick Byers wrote:
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 forumhere
,
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

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

[Mike Taylor]

Yep - that is an official positive signal, thanks!

On 1/24/24 7:40 PM, Francis McCabe wrote:
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) 
 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 experimentationThis 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&q=owner%3Ame&can=2



Estimated milestonesOriginTrial desktop last130OriginTrial
desktop first122OriginTrial Android last130OriginTrial Android
first122OriginTrial webView las

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

['Andy Luhrs' via blink-dev]

Excited about the potential changes around COEP, Microsoft has a handful of 
apps in that situation and we'd love to chat more if there's more 
supporting evidence/discussion needed.

On Friday, January 19, 2024 at 9:15:52 AM UTC-8 rby...@chromium.org wrote:

> LGTM to extend. Breaking the transitive dependency problem with OOPIF 
> seems like an effective and pragmatic strategy to me, I'm excited to see 
> where that goes.
>
> One nit below.
>
> On Fri, Jan 19, 2024 at 12:06 PM Camille Lamy  wrote:
>
>> Contact emails
>>
>> va...@chromium.org cl...@chromium.org
>>
>> Explainer
>>
>>
>> https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k
>>
>> Specification
>>
>> https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects
>>
>> Design docs Including the new security requirements
>>
>>
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
>>
>> Discussion how and what to gate
>>
>> https://github.com/whatwg/html/issues/4732
>>
>> Summary
>>
>> ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to 
>> cross-origin isolated environments, matching the behavior we've recently 
>> shipped on Android and Firefox. We've performed that change in Chrome 92. A 
>> reverse OT was started to give developers the option to use SABs in case 
>> they are not able to adopt cross origin isolation yet.
>>
>> We’ve worked with multiple internal and external users of the OT to 
>> understand their use cases and why they can’t adopt yet. With 
>> COEP:credentialless and iframes credentialless now available, the SAB non 
>> COI usage went further down.
>>
>> Unfortunately, the cascading requirements of COEP are still a blocker for 
>> COI adoption. Some of the users of the OT rely heavily on credentialled 
>> cross-origin subresources, so credentialless modes are not an option for 
>> them. And their apps are complex enough that they are still blocked on 
>> child iframes supporting COEP.
>>
>> To address this, we’re exploring ways of enabling COI that would take 
>> advantage of process isolation in order to waive requirements on child 
>> frames to enforce COEP. However, this is still at an exploratory stage. So 
>> we would like to request a 3 milestones extension (until M124) to this 
>> deprecation trial. This will give us enough time to propose a solution and 
>> discuss it with the standards community and users of the reverse OT. We 
>> will then come back with a proposed solution to finally end the OT and get 
>> the remaining users of the reverse OT, as well as a timeline for the OT 
>> ending.
>> Blink component
>>
>> Blink>JavaScript 
>> 
>>
>> Search tags
>>
>> SharedArrayBuffer 
>> , SAB 
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/471
>> TAG review statusClosed
>> RisksInteroperability and Compatibility
>>
>> We expect this change to negatively impact developers using 
>> `SharedArrayBuffer` today. Chrome was the only platform where SABs have 
>> been available without COOP/COEP. Therefore we need to give developers the 
>> right capabilities and a clear path forward to ensure they’ve enough time 
>> to adopt. We aim to mitigate these risks by adopting a longer-than-usual 
>> depreciation period with console warnings/issues and a reverse origin 
>> trial. 
>>
>> Good news is usage is down to ~0.0209% 
>> 
>>  
>> page loads and that other browsers have or are shipping SABs again gated 
>> behind COOP/COEP. Bad news is that Chromium was the only browser that 
>> supported SABs without COI, therefore we need to provide a migration path 
>> to not break existing sites.
>>
>
> Is it really "down"? The graph 
>  is up 
> and down, but overall seems like an upward trend over the past two years, 
> not a downward one, right? If anything that should make the argument for 
> urgency on an alternative adoption strategy like you propose higher (not 
> something we can fix with more outreach and time).
>
>> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)
>>
>> WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No - This OT is only for desktop, as this was the only platform where 
>> SABs have been available without COOP/COEP.
>>
>> Android re-enabled SABs gated behind COOP/COEP: 
>> https://chromestatus.com/feature/5171863141482496
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1144104
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issue

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' via blink-dev]

On Wed, Jan 24, 2024 at 8:29 PM Domenic Denicola 
wrote:

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

Done.


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

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

[Thomas Guilbert]

Thank you Wesley for the useful information!

> What timeline do you have in mind?
I'm not sure what reasonable timelines are, not having dealt with
deprecations before. Is 3 months for a deprecation trial acceptable?
Devtools should already have deprecation warnings
,
but I don't see them in my console.

I had looked at the only site listed for the
https://chromestatus.com/metrics/feature/timeline/popularity/170
use-counter. They are directly calling the API for their overlay welcome
video, but the page seemed to work fine with the API disabled. I don't
think the fullscreen actually happens, without the user interaction...

This use counter shows a spike up from December to January
https://chromestatus.com/metrics/feature/timeline/popularity/168. 5 links
are using https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js, one link is
also playing an overlay video intro.

On Thu, Jan 25, 2024 at 12:25 AM Philip Jägenstedt 
wrote:

> I'm also happy to support a plan to deprecate and remove. The use counter
> that best represents worst-case user impact at
> https://chromestatus.com/metrics/feature/timeline/popularity/170 at
> ~0.001%. But that's only when fullscreen actually happens (on user
> interaction) and it's very hard to say what proportion of sites could
> *potentially* hit this code path, especially given the ubiquitous pattern
> of trying multiple API names that's been necessary forever with fullscreen,
> so that some sites will just fall back to a working API.
>
> What timeline do you have in mind?
>
> On Thu, Jan 25, 2024 at 2:19 AM Domenic Denicola 
> wrote:
>
>> 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

Re: [blink-dev] Request for Deprecation Trial: Deprecate Third-Party Cookies

['Johann Hofmann' via blink-dev]

Hi all, to follow up here, we're happy to share that the first-party 
Deprecation Trial (DT for top-level sites) for 3PCD is now available. See 
below resources for more details:

Announcement blog: 
https://developers.google.com/privacy-sandbox/blog/3pcd-first-party-deprecation-trial-available

Documentation: 
https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/first-party-deprecation-trial

Thanks,
Johann

On Friday, January 19, 2024 at 9:26:23 PM UTC+1 wande...@chromium.org wrote:

> On Fri, Jan 19, 2024 at 2:27 PM Brett McStotts  
> wrote:
>
>> I'm interested in the first-party version of the 3PDC Deprecation Trial 
>> for top-level origins. I've already registered my domain for the DT for the 
>> third-party version. My token is technically already first-party; I did not 
>> enable "Third-party matching" as instructed 
>> 
>>  
>> under providing the token in an HTTP header. Can I use my existing token 
>> for the upcoming first-party version for top-level origins? Or will this be 
>> a separate registration process where I need a different token? 
>
>
> The upcoming first-party DT will be a separate trial and require a 
> separate token.
>
> Also note, the "Third-party matching" is only relevant to how you want to 
> deploy the token.  For the existing third-party DT clicking this option 
> allows you to deploy the token via a 3P script instead of on an embedded 
> iframe.
>  
>
>> On Wednesday, January 17, 2024 at 7:42:38 AM UTC-5 joha...@google.com 
>> wrote:
>>
>>> Hi all, a brief update that the team is still working on setting up the 
>>> first-party version of this Deprecation Trial.
>>>
>>> In the meantime, if you're a developer experiencing breakage on your 
>>> site and are planning to apply to the first-party DT, please file a 
>>> breakage report via https://goo.gle/report-3pc-broken at your earliest 
>>> convenience to support faster processing once the DT registration opens.
>>>
>>> Thanks,
>>>
>>> Johann
>>>
>>> On Tue, Dec 26, 2023 at 5:13 PM Chris Harrelson  
>>> wrote:
>>>
 LGTM

 On Tue, Dec 26, 2023 at 8:11 AM 'Joshua Hood' via blink-dev <
 blin...@chromium.org> wrote:

> Hi Blink API owners,
>
> We would like to request your approval for adding a first-party 
> version of this Deprecation Trial. This will be helpful for top-level 
> origins that also need additional transition time, in cases where it is 
> impossible, impractical or unnecessary to sign the affected third-party 
> (3P) providers up for the 3P deprecation trial. This deprecation trial 
> temporarily provides cross-site cookie access for non-advertising use 
> cases.
>
> This has been requested by web developers on threads such as the I2D&R 
> thread 
> 
>  
> for third-party cookies.
>
> Our proposed timelines for this trial remain unchanged:
>
> Registration opens the week of January 15, 2024 [1]
>
> The trial will end on December 27, 2024
>
> Effective in Chrome versions M120 through M132
>
> [1] As communicated previously, the grace period 
> 
>  
> that we are providing for the third-party deprecation trial also applies 
> to 
> the first-party deprecation trial. Additionally, to minimize user 
> impact before registration for the trial opens, Chrome will provide 
> temporary access to third-party cookies for sites with reported 
>  user-facing breakage during this 
> grace period.
>
> On Tuesday, December 5, 2023 at 3:53:04 PM UTC-5 Ben Kelly wrote:
>
>> FYI, we are also planning to provide a grace period for sites 
>> registered and approved for the deprecation trial to give them time to 
>> deploy trial tokens.  See this updated section of the blog post:
>>
>>
>> https://developers.google.com/privacy-sandbox/blog/third-party-cookie-deprecation-trial#:~:text=We%20acknowledge%20that,the%20grace%20period
>> .
>>
>> On Tue, Dec 5, 2023 at 12:22 PM Ben Kelly  
>> wrote:
>>
>>> The deprecation trial is now open for registrations:
>>>
>>>
>>> https://developer.chrome.com/origintrials/#/view_trial/3315212275698106369
>>>
>>> Again, please be aware this trial will require a review process as 
>>> outlined in the blog pos 
>>> 

[blink-dev] Intent to Prototype: 'writingsuggestions' attribute

['Stephanie Zhang' via blink-dev]

Contact emails
sa...@microsoft.com, 
dan...@microsoft.com, 
stephanie.zh...@microsoft.com


Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md


Specification
Add a new attribute called `writingsuggestions` to control UA-provided writing 
assistance by sanketj * Pull Request #10018 * whatwg/html 
(github.com)


Summary
The new attribute 'writingsuggestions' has values on/off that would allow 
developers to turn on/off browser-provided writing suggestions. This attribute 
will have a default state per element, as established by the UA. The 
attribute's state for an element can also be inherited from ancestor elements, 
thereby allowing developers to control this functionality at a per-element or 
per-document/sub-document scale.


Blink component
Blink>Editing


Motivation
UAs are starting to provide writing suggestions to users as they type on 
various editable fields across the web. While this is generally useful for 
users, there are cases when developers may want to turn off UA-provided writing 
assistance, such as extensions or sites that wish to provide similar 
functionality on their own. To that end, developers need a solution that would 
turn on/off UA-provided writing assistance.


Initial public proposal
New attribute to control UA-provided writing assistance * Issue #9065 * 
whatwg/html (github.com)


TAG review
New attribute to control UA-provided writing assistance * Issue #924 * 
w3ctag/design-reviews * 
GitHub


TAG review status
Resolution: satisfied


Risks
None


Interoperability and Compatibility
None

Gecko: Pending (New attribute to control UA-provided writing assistance * Issue 
#855 * mozilla/standards-positions * 
GitHub)

WebKit: Pending (New attribute to control UA-provided writing assistance * 
Issue #308 * WebKit/standards-positions 
(github.com)). See 
also (https://github.com/whatwg/html/issues/9065#issuecomment-1487106100)

Web developers: No signals

Other signals: None


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?
This PR will add tests: Add tests for the writingsuggestions attribute by 
sanketj * Pull Request #43780 * web-platform-tests/wpt * 
GitHub


Flag name on chrome://flags
None


Finch feature name
None


Non-finch justification
None


Requires code in //chrome?
False


Estimated milestones
No milestones specified


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

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/MN2PR00MB08649EF7677C7E81B876E9EDEC7A2%40MN2PR00MB0864.namprd00.prod.outlook.com.

[blink-dev] PSA: vpython (2.7) to be removed from depot_tools

['Brian Ryner' via infra-announce]

depot_tools users,

Next week on January 31 (US time), we will submit
https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/5187892
to remove the old vpython package (powered by python 2.7) from depot_tools.

vpython3 will remain part of depot_tools, supporting python 3.8 and 3.11.

At this point we are not aware of any builders or developer workflows that
rely on depot_tools vpython. If you have any concerns, please leave  a
comment in https://crbug.com/1376538, or file a bug block on 1376538.

Thanks,

-- 
You received this message because you are subscribed to the Google Groups 
"infra-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to infra-announce+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/infra-announce/CAK8VFA-__kQ%2Bku1Z%2BCS-Vdw%3DD5%3DkWGCoc4QQmskENdzt6t0%2BSg%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/CAK8VFA-__kQ%2Bku1Z%2BCS-Vdw%3DD5%3DkWGCoc4QQmskENdzt6t0%2BSg%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]

LGTM3

On Fri, Jan 26, 2024 at 4:10 AM Paul Jensen  wrote:

>
>
> On Wed, Jan 24, 2024 at 8:29 PM Domenic Denicola 
> wrote:
>
>>
>>
>> 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?
>>
>
> Done.
>
>
>>
>>
>>>
>>> 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 M12

[blink-dev] PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

We plan to start enabling the k-anonymity

enforcement feature for the Protected Audience API
 (Intent to Ship
).
K-anonymity enforcement has long been a part of the Protected Audience
API’s plan for improving user privacy by limiting ads that can win
Protected Audience auctions to those ads that are k-anonymous. The
k-anonymity enforcement feature limits the ability of advertisers to target
specific users by requiring each ad be shown to a minimum number of users.
This enforcement will initially apply to up to 20% of unlabeled traffic
only, meaning the groups that are part of Chrome-facilitated testing

for third-party cookie deprecation will not be enforced for k-anonymity
during the testing period. After the testing period, enforcement will apply
to all traffic (see timeline details at
https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
).

-- 
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com.