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

['Thomas Guilbert' via blink-dev]

Ok for a 6 months trial, with the possibility to extend it further. I will
wait for the remaining security/privacy approvals and then update this
thread again.

Additionally, someone commented on the WebKit positions standards thread

that
the next version of Safari will have support for the fullscreen API (still
subject to change before shipping). It would be great timing if the API
ships on iOS, to minimize the work for web authors as they switch away from
the API.

On Fri, Jan 26, 2024 at 6:26 AM Philip Jägenstedt 
wrote:

> https://sites.google.com/a/chromium.org/dev/blink/launching-features
> doesn't give any guidance on the timeline, so let's just pick a timeline
> that makes sense for this case. It's been up to a year in other cases.
>
> Since feature detection is common, we have to remove the whole API surface
> and let code that depends on it throw exceptions. We won't be able to print
> anything helpful to the console informing developers that there is a
> deprecation trial. From their point of view it will simply be removed, and
> they might find out about the deprecation trial if they do some further
> research.
>
> Since the cost of supporting these APIs is very low, I think we
> should give developers plenty of time. But usage is already so low that
> it's not a certainty that anyone will really use the trial. So how about we
> start with 6 months, and if we see that there are sites using the trial to
> re-enable the feature, then we extend it by another 6 months. Would that
> work?
>
> On Thu, Jan 25, 2024 at 9:22 PM Thomas Guilbert 
> wrote:
>
>> 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 

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

[Ari Chivukula]

Please note the repo has been moved into PrivacyCG, and the new links are:
Explainer: Extending Storage Access API (SAA) to non-cookie storage

Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies

Explainer: Extending Storage Access API (SAA) to Shared Workers

Discussion 

~ Ari Chivukula (Their/There/They're)


On Wed, Jan 17, 2024 at 3:06 PM Ari Chivukula  wrote:

> Two additional explainers (each of which is an extension to Storage
> Access API (SAA) to non-cookie storage
> ) have been published!
> Both of these are slated for inclusion in the existing origin trial
> (hopefully as part of M123).
>
> Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies
> 
> The current Storage Access API requires that unpartitioned cookie access
> is granted if any unpartitioned storage access is needed. This forces
> unpartitioned cookies to be included in network requests which may not need
> them, having impacts on network performance and security. Before the
> extension ships, we have a chance to fix this behavior without a
> compatibility break.
>
> Explainer: Extending Storage Access API (SAA) to Shared Workers
> 
> There has been increasing developer and implementer interest in
> first-party workers being available in third-party contexts the same way
> that third-party cookies already can be. In the absence of such a solution,
> we leave developers without a robust way to manage cross-tab state for
> frames loading the same origin. This explainer proposes a solution for
> developers to regain third-party access to Shared Workers in select
> instances to avoid user-facing breakage in browsers shipping storage
> partitioning.
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Tue, Jan 9, 2024 at 3:03 PM Ari Chivukula  wrote:
>
>> Based on a report from an external developer
>> 
>>  a
>> bug was found that caused the session/local storage on the SAA handle to
>> sometimes be partitioned (instead of unpartitioned). The fix
>>  will
>> be included in M122.
>>
>> Please report any further issues to
>> https://github.com/arichiv/saa-non-cookie-storage/issues, thanks!
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Mon, Dec 4, 2023 at 9:54 AM Ari Chivukula 
>> wrote:
>>
>>> A blog post on how to participate in the OT is here:
>>> https://developer.chrome.com/blog/saa-non-cookie-storage/
>>>
>>> Chrome 120 includes local storage, session storage, indexed db, and web
>>> locks.
>>>
>>> Chrome 121 adds cache storage, origin private filesystem, quota, blob
>>> storage, and broadcast channel.
>>>
>>> Shared Workers will be re-examined in a future extension, I hope to
>>> publish more on this within a month.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Thu, Oct 26, 2023 at 11:21 AM Ari Chivukula 
>>> wrote:
>>>
 Contact emails

 aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
 hele...@google.com


 Specification

 https://arichiv.github.io/saa-non-cookie-storage/


 Feedback

 https://github.com/arichiv/saa-non-cookie-storage/issues


 Intent to Prototype

 https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0


 Summary

 An origin trial
 ,
 StorageAccessAPIBeyondCookies, will be made available which enables the
 proposed extension of the Storage Access API
 
 (backwards compatible) to allow access to unpartitioned (cookie and
 non-cookie) storage in a third-party context. The current API only provides
 access to cookies, which have different use-cases than non-cookie storage
 (discussed more in the Motivation section). The API can be used as follows
 (JS running in an embedded iframe):


 // Request a new storage handle via rSA (this should prompt the user)

 let handle = await document.requestStorageAccess({all: true});

 // Write some 1P context sessionstorage

 handle.sessionStorage.setItem("userid", "1234");

 // Write some 1P context localstorage

 handle.localStorage.setItem("preference", "A");

 // Open or create an indexedDB that is shared with the 1P context

 let messageDB = 

Re: [blink-dev] Intent to Ship: NavigationActivation

[Noam Rosenthal]

On Mon, Jan 29, 2024 at 1:30 PM Mike Taylor  wrote:

> On 1/29/24 2:44 AM, 'Noam Rosenthal' via blink-dev wrote:
>
> On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote:
>
> On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal 
> wrote:
>
>
> Finch feature nameNone
>
> Non-finch justification
>
> It's a web-API, exposing it gradually doesn't make sense.
>
>
> I'm always unsure about this, but I believe "Finch feature name" is the
> flag you'd put in runtime_enabled_features.json5. It can be used by Finch
> as a kill-switch in case the feature causes some regression in the wild.
> For this feature, the chrome:://flags flag isn't there though (correct me
> if I'm wrong)
>
>
> According to these guidelines:
> https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#guidelines-for-setting-feature-status
> Finch + base:: features are used only for things that can cause compat
> issues, not so much for new web APIs.
> I was following this guideline, if something else is required here I'd be
> happy to follow up.
>
> See
> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required.
> The new guidance (since Aug 2022) is to add a flag for ~mostly everything.
>

Right, of course. But those are auto-generated from blink flags.
So, we do have a finch flag, with the same name (NavigationActivation).
I've updated the entry. Sorry for the confusion.

-- 
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%3DMYbvzEuXsCZt2Y57sw9oatDU-Lp-%2BL%3DQ%2BPkhWScj4a3ouQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: NavigationActivation

[Mike Taylor]

On 1/29/24 2:44 AM, 'Noam Rosenthal' via blink-dev wrote:


On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote:

On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal
 wrote:


Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.


I'm always unsure about this, but I believe "Finch feature name"
is the flag you'd put in runtime_enabled_features.json5. It can be
used by Finch as a kill-switch in case the feature causes some
regression in the wild. For this feature, the chrome:://flags flag
isn't there though (correct me if I'm wrong)


According to these guidelines: 
https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#guidelines-for-setting-feature-status
Finch + base:: features are used only for things that can cause compat 
issues, not so much for new web APIs.
I was following this guideline, if something else is required here I'd 
be happy to follow up.


See 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required. 
The new guidance (since Aug 2022) is to add a flag for ~mostly everything.


--
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/fc780a9b-78e0-4d79-892a-181786a5201b%40chromium.org.

[blink-dev] Intent to Prototype: WebGPU: ServiceWorker and SharedWorker support

['François Beaufort' via blink-dev]

Contact emailsfbeauf...@google.com

Specificationhttps://gpuweb.github.io/gpuweb/#navigator-gpu

Summary

Functionality added to the WebGPU spec after its first shipment in a
browser. ServiceWorker and SharedWorker support is added to WebGPU,
aligning with existing WebGL capabilities.
Blink componentBlink>WebGPU


Motivation

WebGPU being exposed to ServiceWorker and SharedWorker would open up
opportunities such as building AI browser extensions with WebGPU.

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and CompatibilityServiceWorker and SharedWorker support
have not yet been implemented in any browser, but have been approved by the
GPU for the Web Community Group, with representatives from Chrome, Firefox,
and Safari.

Minutes:
https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43


*Gecko*: No signal

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933
)

*Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4197)

*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://bugs.chromium.org/p/chromium/issues/detail?id=1521763

Estimated milestones

No milestones specified


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

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/CAPpwU5%2BewUL-PTEQ_ZQgdtViKU2fSVXeDNab2oEy6RsGqkgcGQ%40mail.gmail.com.