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

['Thomas Guilbert' via blink-dev]

FYI, the enterprise policy landed in M124 (under
"PrefixedVideoFullscreenApiAvailability"), and the deprecation trial will
activate when M125 branches, on April 15th.

On Fri, Feb 2, 2024 at 12:16 PM Mike Taylor  wrote:

> LGTM3
> On 2/2/24 1:03 AM, Domenic Denicola wrote:
>
> LGTM2. Please be sure to update Chrome Status with the deprecation trial
> timelines and removal milestones so that data gets fed into the feature
> dashboard, beta blog posts, etc.
>
> On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
> wrote:
>
>> Thank you!
>>
>> I will be adding an enterprise policy to re-enable the APIs if necessary,
>> as part of the enterprise review. Deprecating the enterprise policy will
>> become the new objective after the proper amount of time has elapsed,
>> before the code can be deleted for good.
>>
>> I will keep updating this thread as I make it further in the launch
>> process.
>>
>> On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
>> wrote:
>>
>>> Thank you Thomas!
>>>
>>> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
>>> disable the APIs by default and at the same time start a reverse origin
>>> trial to re-enable them for 6 months. If you hear feedback requesting an
>>> extension towards the end of those 6 months, please request an extension
>>> for another 6 months.
>>>
>>> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
>>> wrote:
>>>
 Thanks for marking it for review!

 I submitted a request to review this change to the chromium enterprise
 mailing list.

 Thanks,
 Thomas

 On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
 wrote:

> Yep - seems that's the cause of confusion. In your first email,
> https://chromestatus.com/feature/5259513871466496 is linked from the
> bottom, so our review tooling is presenting that to us. But I've just
> flagged the new one so it will show up as well.
>
> thanks!
> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>
> I requested privacy/security/debuggability on the video element
> fullscreen API deprecation feature
>  
> last
> week. Privacy and debuggability are approved, just waiting on security.
>
> Mike, are you talking about requesting those gates on the original
> Prefixed Fullscreen API feature
> ? I don't have
> edit rights on that Chrome status entry, and upon closer look, it relates
> to `webkitRequestFullscreen`, which is not covered by this deprecation
> intent.
>
> > [...] requesting enterprise signoff [...]
> Is this a field on the chrome status entry? It doesn't show up for me.
> Or is this about emailing the list mentioned here
> 
> ?
>
> Thanks,
> Thomas
>
>
>
> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
> wrote:
>
>> Apologies in advance for excessive paperwork, but can you also put
>> https://chromestatus.com/feature/5111638103687168 through the
>> process, requesting enterprise signoff in particular? Enterprise folks
>> could depend on this and might need to take some extra action, and a
>> "Feature deprecation" entry is the only way we can flag that.
>>
>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>> wrote:
>>
>>> Gentle reminder to follow up on requesting
>>> privacy/security/debuggability approvals in chromestatus (which is
>>> currently blocking LGTMs).
>>>
>>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>>
 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 

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

[Mike Taylor]

LGTM3

On 2/2/24 1:03 AM, Domenic Denicola wrote:
LGTM2. Please be sure to update Chrome Status with the deprecation 
trial timelines and removal milestones so that data gets fed into the 
feature dashboard, beta blog posts, etc.


On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
 wrote:


Thank you!

I will be adding an enterprise policy to re-enable the APIs if
necessary, as part of the enterprise review. Deprecating the
enterprise policy will become the new objective after the proper
amount of time has elapsed, before the code can be deleted for good.

I will keep updating this thread as I make it further in the
launch process.

On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt
 wrote:

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so
LGTM1 to disable the APIs by default and at the same time
start a reverse origin trial to re-enable them for 6 months.
If you hear feedback requesting an extension towards the end
of those 6 months, please request an extension for another 6
months.

On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert
 wrote:

Thanks for marking it for review!

I submitted a request to review this change to the
chromium enterprise mailing list.

Thanks,
Thomas

On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor
 wrote:

Yep - seems that's the cause of confusion. In your
first email,
https://chromestatus.com/feature/5259513871466496 is
linked from the bottom, so our review tooling is
presenting that to us. But I've just flagged the new
one so it will show up as well.

thanks!

On 1/31/24 2:41 PM, Thomas Guilbert wrote:

I requested privacy/security/debuggability on the
video element fullscreen API deprecation feature

 last
week. Privacy and debuggability are approved, just
waiting on security.

Mike, are you talking about requesting those gates on
the original Prefixed Fullscreen API feature
?
I don't have edit rights on that Chrome status entry,
and upon closer look, it relates to
`webkitRequestFullscreen`, which is not covered by
this deprecation intent.

> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It
doesn't show up for me. Or is this about emailing the
list mentioned here

?

Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt
 wrote:

Apologies in advance for excessive paperwork, but
can you also put
https://chromestatus.com/feature/5111638103687168
through the process, requesting enterprise
signoff in particular? Enterprise folks could
depend on this and might need to take some extra
action, and a "Feature deprecation" entry is the
only way we can flag that.

On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor
 wrote:

Gentle reminder to follow up on requesting
privacy/security/debuggability approvals in
chromestatus (which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM
UTC-5 Mike Taylor wrote:

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
 

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

[Domenic Denicola]

LGTM2. Please be sure to update Chrome Status with the deprecation trial
timelines and removal milestones so that data gets fed into the feature
dashboard, beta blog posts, etc.

On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
wrote:

> Thank you!
>
> I will be adding an enterprise policy to re-enable the APIs if necessary,
> as part of the enterprise review. Deprecating the enterprise policy will
> become the new objective after the proper amount of time has elapsed,
> before the code can be deleted for good.
>
> I will keep updating this thread as I make it further in the launch
> process.
>
> On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
> wrote:
>
>> Thank you Thomas!
>>
>> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
>> disable the APIs by default and at the same time start a reverse origin
>> trial to re-enable them for 6 months. If you hear feedback requesting an
>> extension towards the end of those 6 months, please request an extension
>> for another 6 months.
>>
>> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
>> wrote:
>>
>>> Thanks for marking it for review!
>>>
>>> I submitted a request to review this change to the chromium enterprise
>>> mailing list.
>>>
>>> Thanks,
>>> Thomas
>>>
>>> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
>>> wrote:
>>>
 Yep - seems that's the cause of confusion. In your first email,
 https://chromestatus.com/feature/5259513871466496 is linked from the
 bottom, so our review tooling is presenting that to us. But I've just
 flagged the new one so it will show up as well.

 thanks!
 On 1/31/24 2:41 PM, Thomas Guilbert wrote:

 I requested privacy/security/debuggability on the video element
 fullscreen API deprecation feature
  
 last
 week. Privacy and debuggability are approved, just waiting on security.

 Mike, are you talking about requesting those gates on the original
 Prefixed Fullscreen API feature
 ? I don't have edit
 rights on that Chrome status entry, and upon closer look, it relates to
 `webkitRequestFullscreen`, which is not covered by this deprecation intent.

 > [...] requesting enterprise signoff [...]
 Is this a field on the chrome status entry? It doesn't show up for me.
 Or is this about emailing the list mentioned here
 
 ?

 Thanks,
 Thomas



 On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
 wrote:

> Apologies in advance for excessive paperwork, but can you also put
> https://chromestatus.com/feature/5111638103687168 through the
> process, requesting enterprise signoff in particular? Enterprise folks
> could depend on this and might need to take some extra action, and a
> "Feature deprecation" entry is the only way we can flag that.
>
> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
> wrote:
>
>> Gentle reminder to follow up on requesting
>> privacy/security/debuggability approvals in chromestatus (which is
>> currently blocking LGTMs).
>>
>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>
>>> 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 

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

[Thomas Guilbert]

Thank you!

I will be adding an enterprise policy to re-enable the APIs if necessary,
as part of the enterprise review. Deprecating the enterprise policy will
become the new objective after the proper amount of time has elapsed,
before the code can be deleted for good.

I will keep updating this thread as I make it further in the launch process.

On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
wrote:

> Thank you Thomas!
>
> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
> disable the APIs by default and at the same time start a reverse origin
> trial to re-enable them for 6 months. If you hear feedback requesting an
> extension towards the end of those 6 months, please request an extension
> for another 6 months.
>
> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
> wrote:
>
>> Thanks for marking it for review!
>>
>> I submitted a request to review this change to the chromium enterprise
>> mailing list.
>>
>> Thanks,
>> Thomas
>>
>> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
>> wrote:
>>
>>> Yep - seems that's the cause of confusion. In your first email,
>>> https://chromestatus.com/feature/5259513871466496 is linked from the
>>> bottom, so our review tooling is presenting that to us. But I've just
>>> flagged the new one so it will show up as well.
>>>
>>> thanks!
>>> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>>>
>>> I requested privacy/security/debuggability on the video element
>>> fullscreen API deprecation feature
>>>  
>>> last
>>> week. Privacy and debuggability are approved, just waiting on security.
>>>
>>> Mike, are you talking about requesting those gates on the original
>>> Prefixed Fullscreen API feature
>>> ? I don't have edit
>>> rights on that Chrome status entry, and upon closer look, it relates to
>>> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>>>
>>> > [...] requesting enterprise signoff [...]
>>> Is this a field on the chrome status entry? It doesn't show up for me.
>>> Or is this about emailing the list mentioned here
>>> 
>>> ?
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>>
>>> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
>>> wrote:
>>>
 Apologies in advance for excessive paperwork, but can you also put
 https://chromestatus.com/feature/5111638103687168 through the process,
 requesting enterprise signoff in particular? Enterprise folks could depend
 on this and might need to take some extra action, and a "Feature
 deprecation" entry is the only way we can flag that.

 On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
 wrote:

> Gentle reminder to follow up on requesting
> privacy/security/debuggability approvals in chromestatus (which is
> currently blocking LGTMs).
>
> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>
>> 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
>> 

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

[Philip Jägenstedt]

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so LGTM1 to
disable the APIs by default and at the same time start a reverse origin
trial to re-enable them for 6 months. If you hear feedback requesting an
extension towards the end of those 6 months, please request an extension
for another 6 months.

On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
wrote:

> Thanks for marking it for review!
>
> I submitted a request to review this change to the chromium enterprise
> mailing list.
>
> Thanks,
> Thomas
>
> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
> wrote:
>
>> Yep - seems that's the cause of confusion. In your first email,
>> https://chromestatus.com/feature/5259513871466496 is linked from the
>> bottom, so our review tooling is presenting that to us. But I've just
>> flagged the new one so it will show up as well.
>>
>> thanks!
>> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>>
>> I requested privacy/security/debuggability on the video element
>> fullscreen API deprecation feature
>>  
>> last
>> week. Privacy and debuggability are approved, just waiting on security.
>>
>> Mike, are you talking about requesting those gates on the original
>> Prefixed Fullscreen API feature
>> ? I don't have edit
>> rights on that Chrome status entry, and upon closer look, it relates to
>> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>>
>> > [...] requesting enterprise signoff [...]
>> Is this a field on the chrome status entry? It doesn't show up for me. Or
>> is this about emailing the list mentioned here
>> 
>> ?
>>
>> Thanks,
>> Thomas
>>
>>
>>
>> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
>> wrote:
>>
>>> Apologies in advance for excessive paperwork, but can you also put
>>> https://chromestatus.com/feature/5111638103687168 through the process,
>>> requesting enterprise signoff in particular? Enterprise folks could depend
>>> on this and might need to take some extra action, and a "Feature
>>> deprecation" entry is the only way we can flag that.
>>>
>>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>>> wrote:
>>>
 Gentle reminder to follow up on requesting
 privacy/security/debuggability approvals in chromestatus (which is
 currently blocking LGTMs).

 On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:

> 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 

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

['Thomas Guilbert' via blink-dev]

Thanks for marking it for review!

I submitted a request to review this change to the chromium enterprise
mailing list.

Thanks,
Thomas

On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor  wrote:

> Yep - seems that's the cause of confusion. In your first email,
> https://chromestatus.com/feature/5259513871466496 is linked from the
> bottom, so our review tooling is presenting that to us. But I've just
> flagged the new one so it will show up as well.
>
> thanks!
> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>
> I requested privacy/security/debuggability on the video element
> fullscreen API deprecation feature
>  last
> week. Privacy and debuggability are approved, just waiting on security.
>
> Mike, are you talking about requesting those gates on the original
> Prefixed Fullscreen API feature
> ? I don't have edit
> rights on that Chrome status entry, and upon closer look, it relates to
> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>
> > [...] requesting enterprise signoff [...]
> Is this a field on the chrome status entry? It doesn't show up for me. Or
> is this about emailing the list mentioned here
> 
> ?
>
> Thanks,
> Thomas
>
>
>
> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
> wrote:
>
>> Apologies in advance for excessive paperwork, but can you also put
>> https://chromestatus.com/feature/5111638103687168 through the process,
>> requesting enterprise signoff in particular? Enterprise folks could depend
>> on this and might need to take some extra action, and a "Feature
>> deprecation" entry is the only way we can flag that.
>>
>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>> wrote:
>>
>>> Gentle reminder to follow up on requesting
>>> privacy/security/debuggability approvals in chromestatus (which is
>>> currently blocking LGTMs).
>>>
>>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>>
 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 

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

[Mike Taylor]

Yep - seems that's the cause of confusion. In your first email, 
https://chromestatus.com/feature/5259513871466496 is linked from the 
bottom, so our review tooling is presenting that to us. But I've just 
flagged the new one so it will show up as well.


thanks!

On 1/31/24 2:41 PM, Thomas Guilbert wrote:
I requested privacy/security/debuggability on the video element 
fullscreen API deprecation feature 
 last 
week. Privacy and debuggability are approved, just waiting on security.


Mike, are you talking about requesting those gates on the original 
Prefixed Fullscreen API feature 
? I don't have edit 
rights on that Chrome status entry, and upon closer look, it relates 
to `webkitRequestFullscreen`, which is not covered by this deprecation 
intent.


> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It doesn't show up for me. 
Or is this about emailing the list mentioned here 
?


Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
 wrote:


Apologies in advance for excessive paperwork, but can you also put
https://chromestatus.com/feature/5111638103687168 through the
process, requesting enterprise signoff in particular? Enterprise
folks could depend on this and might need to take some extra
action, and a "Feature deprecation" entry is the only way we can
flag that.

On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor
 wrote:

Gentle reminder to follow up on requesting
privacy/security/debuggability approvals in chromestatus
(which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor
wrote:

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

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

[Thomas Guilbert]

I requested privacy/security/debuggability on the video element fullscreen
API deprecation feature
 last
week. Privacy and debuggability are approved, just waiting on security.

Mike, are you talking about requesting those gates on the original Prefixed
Fullscreen API feature ?
I don't have edit rights on that Chrome status entry, and upon closer look,
it relates to `webkitRequestFullscreen`, which is not covered by this
deprecation intent.

> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It doesn't show up for me. Or
is this about emailing the list mentioned here

?

Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
wrote:

> Apologies in advance for excessive paperwork, but can you also put
> https://chromestatus.com/feature/5111638103687168 through the process,
> requesting enterprise signoff in particular? Enterprise folks could depend
> on this and might need to take some extra action, and a "Feature
> deprecation" entry is the only way we can flag that.
>
> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
> wrote:
>
>> Gentle reminder to follow up on requesting privacy/security/debuggability
>> approvals in chromestatus (which is currently blocking LGTMs).
>>
>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>
>>> 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 

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

[Philip Jägenstedt]

Apologies in advance for excessive paperwork, but can you also put
https://chromestatus.com/feature/5111638103687168 through the process,
requesting enterprise signoff in particular? Enterprise folks could depend
on this and might need to take some extra action, and a "Feature
deprecation" entry is the only way we can flag that.

On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor  wrote:

> Gentle reminder to follow up on requesting privacy/security/debuggability
> approvals in chromestatus (which is currently blocking LGTMs).
>
> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>
>> 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:
>> 

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

[Mike Taylor]

Gentle reminder to follow up on requesting privacy/security/debuggability 
approvals in chromestatus (which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:

> 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 

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

[Philip Jägenstedt]

Thanks Thomas, looking forward to being able to say LGTM to this :)

I agree that it would be ideal if the unprefixed API is supported on iOS
before we remove the video-specific prefixed APIs in Chrome, so that people
can have confidence their updated code will work in both Chrome and Safari.

On Mon, Jan 29, 2024 at 8:43 PM Thomas Guilbert 
wrote:

> 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 

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] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Philip Jägenstedt]

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

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

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

[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] 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] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Domenic Denicola]

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 expensive, and getting rid of
>> them is more worthwhile.
>>
>>
>>> 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%
>>>
>>>
>>>
>> It's notable that the highest counters are for the boolean properties.
>> That makes this slightly less risky, because removing them will cause them
>> to return `undefined`, so code like `if (videoEl.webkitSupportsFullscreen)
>> { ... }` will just return false, instead of throwing an exception or
>> similar.
>>
>>
>>> 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 

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

[Thomas Guilbert]

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.

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?

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 expensive, and getting rid of
> them is more worthwhile.
>
>
>> 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%
>>
>>
>>
> It's notable that the highest counters are for the boolean properties.
> That makes this slightly less risky, because removing them will cause them
> to return `undefined`, so code like `if (videoEl.webkitSupportsFullscreen)
> { ... }` will just return false, instead of throwing an exception or
> similar.
>
>
>> 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
>>
>
> I was going to ask about if there are popular sites or libraries using
> these, but I found some discussion of that in the bug
> . It
> seems like there's a hope that some sites already have fallbacks in place
> to the standardized APIs, but it's not quite clear. Maybe you could try
> running a build of Chromium with the prefixed APIs disabled on a random
> sampling of the HTTP Archive sites, and reporting back on if the user
> experience changes or new errors show up in the JS console? That could give
> us more confidence in the removal.
>
>
>>
>> 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 

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

[Domenic Denicola]

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 expensive, and getting rid of
them is more worthwhile.


> 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%
>
>
>
It's notable that the highest counters are for the boolean properties. That
makes this slightly less risky, because removing them will cause them to
return `undefined`, so code like `if (videoEl.webkitSupportsFullscreen) {
... }` will just return false, instead of throwing an exception or similar.


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

I was going to ask about if there are popular sites or libraries using
these, but I found some discussion of that in the bug
. It
seems like there's a hope that some sites already have fallbacks in place
to the standardized APIs, but it's not quite clear. Maybe you could try
running a build of Chromium with the prefixed APIs disabled on a random
sampling of the HTTP Archive sites, and reporting back on if the user
experience changes or new errors show up in the JS console? That could give
us more confidence in the removal.


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

Based on the WPT results
,
Gecko supports none of the prefixed APIs, and WebKit supports all of them.
I think this is worth noting in the ChromeStatus entry. (Although it's not
an official signal, so leave the dropdown at "No signals".)

Given this, filing a standards-positions issue on WebKit to get their take
on the deprecation might be a good idea. Sometimes those discussions end up
going 

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

[Thomas Guilbert]

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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com.