I've created a new ChromeStatus entry <https://chromestatus.com/feature/5111638103687168>, 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 <dome...@chromium.org> wrote: > > > On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert <tguilb...@chromium.org> > 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 >> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/media/html_video_element.cc;l=418;drc=25705537e65f031d28c1a531046b11914055b7e6>), >> 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 >> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fullscreen/element_fullscreen.idl;l=19;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77> >> 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 <foo...@chromium.org> having done some > computations in the past based on what would actually be statistically > significant. But, I couldn't find them in this documentation > <https://www.chromium.org/blink/platform-predictability/compat-tools/> (or > the linked document > <https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit#heading=h.1m1gg72jnnrt>). > 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 <dome...@chromium.org> >> 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 <tguilb...@chromium.org> >>> wrote: >>> >>>> Contact emails >>>> >>>> tguilb...@chromium.org >>>> >>>> Explainer >>>> >>>> None >>>> >>>> Specification >>>> >>>> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled >>>> >>>> Summary >>>> There was an attempt in 2014 >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61HQPrNK4J> >>>> 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 >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=346236#c74>. 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 >>> <https://wpt.fyi/results/fullscreen/api/historical.html?label=master&label=experimental&aligned&q=%2Ffullscreen%2Fapi%2Fhistorical.html>, >>> 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 in surprising directions; see e.g. this request for a >>> position on the deprecation of mutation events >>> <https://github.com/WebKit/standards-positions/issues/192>. >>> >>> (Gecko also has their own, smaller set of prefixed APIs. But it's not as >>> relevant to this intent about the webkit-prefixed ones.) >>> >>> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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/CABrVPoYM-4J0JKLRL4AkScjcMUsyZng06TVXx9N1wZTgNv9uHA%40mail.gmail.com.
