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 <dome...@chromium.org> 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 <luytenwes...@gmail.com> > 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 >>> <https://github.com/clappr/clappr/issues/2136>. >>> >>> On Wed, Jan 24, 2024 at 3:40 PM Thomas Guilbert <tgui...@chromium.org> >>> wrote: >>> >>>> 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 <dom...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert <tgui...@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 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 <dom...@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 < >>>>>>> tgui...@chromium.org> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> tgui...@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+...@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/CAARdPYfpL2LnSXXfSOMMDLWPRVygoz3BPoZgCLpicAhwWzm36w%40mail.gmail.com.
