Ok for a 6 months trial, with the possibility to extend it further. I will wait for the remaining security/privacy approvals and then update this thread again.
Additionally, someone commented on the WebKit positions standards thread <https://github.com/WebKit/standards-positions/issues/306#issuecomment-1911106462> that the next version of Safari will have support for the fullscreen API (still subject to change before shipping). It would be great timing if the API ships on iOS, to minimize the work for web authors as they switch away from the API. On Fri, Jan 26, 2024 at 6:26 AM Philip Jägenstedt <foo...@chromium.org> wrote: > https://sites.google.com/a/chromium.org/dev/blink/launching-features > doesn't give any guidance on the timeline, so let's just pick a timeline > that makes sense for this case. It's been up to a year in other cases. > > Since feature detection is common, we have to remove the whole API surface > and let code that depends on it throw exceptions. We won't be able to print > anything helpful to the console informing developers that there is a > deprecation trial. From their point of view it will simply be removed, and > they might find out about the deprecation trial if they do some further > research. > > Since the cost of supporting these APIs is very low, I think we > should give developers plenty of time. But usage is already so low that > it's not a certainty that anyone will really use the trial. So how about we > start with 6 months, and if we see that there are sites using the trial to > re-enable the feature, then we extend it by another 6 months. Would that > work? > > On Thu, Jan 25, 2024 at 9:22 PM Thomas Guilbert <tguilb...@chromium.org> > wrote: > >> 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/CABrVPoYGnhFuozAom0X-ccwt5X7qnjyLy8R_DryNGYHTUj3LMQ%40mail.gmail.com.
