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/CAM0wra-h5kZb3dNL%2BX5aXgM-bh8CSzG9SZZWCmoHFPMWAGrALg%40mail.gmail.com.
