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 <https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/generated/Deprecation.ts;l=164;drc=44db243e9d23fa831e59175b1281360404cb31ac>, 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 <foo...@chromium.org> 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 <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/CABrVPoap3PEXTotsfb%3DsoeJ%3D0cTF%3DAeuMO5qTi%2BJLykASJwZUg%40mail.gmail.com.
