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 <tguilb...@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 <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/CABrVPoa2ayp_OmrFH%2B9Q6dS_9nLMwgyZNgUTiL_OkfHBdh6HNw%40mail.gmail.com.
