Intent to Remove: <iframe fullscreenallowed> exemption for the video-specific prefixed fullscreen API

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/DULRMEUkeJw/9HXn55X1gj4J

This deprecated the entire API surface:

HTMLVideoElement.webkitSupportsFullscreen

HTMLVideoElement.webkitDisplayingFullscreen

HTMLVideoElement.webkitEnterFullscreen()

HTMLVideoElement.webkitExitFullscreen()

HTMLVideoElement.webkitEnterFullScreen()

HTMLVideoElement.webkitExitFullScreen()

These have been deprecated since M34. This intent is to remove only one aspect of the API, to align it with the other prefixed fullscreen APIs.

Summary

Remove the exemption from the <iframe fullscreenallowed> check in place for HTMLVideoElement.webkitEnterFullscreen() and HTMLVideoElement.webkitEnterFullScreen() which allows a video to fullscreen when in an iframe even with the fullscreenallowed attribute missing. None of the other Web-exposed code paths have this exemption.

Motivation Ali Alabbas (Microsoft) asked about this on another thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/f-V2GWatXkA/nvdHJ3xihMkJ

The fewer differences we have between the many fullscreen APIs the less painful it will be to transition to the unprefixed API.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/485

https://www.chromestatus.com/metrics/feature/timeline/popularity/168

https://www.chromestatus.com/metrics/feature/timeline/popularity/170

485 counts the cases where fullscreen is entered only due to the exemption, oscillating between 0.0006-0.0009% of page loads. Unfortunately, due to an oversight when the counter was added, this also includes the fullscreen button in <video controls>.

168 and 170 count the two Web-exposed code paths where this exemption could take place, and notably they add up to less than the exemption counter itself, oscillating between 0.0004-0.0006%. This means that <video controls> is at least visible in the data. It seems somewhat unlikely that a large majority of uses of the video-specific prefixed fullscreen API would need this exemption, but since the usage is low enough fixing the use counter and waiting for months doesn't seem warranted.

Entry on chromestatus.com

None.

Compatibility Risk

Worst-case is that all these request will fail, amounting to 0.0006%. Actual breakage ought to be at least a bit smaller, unless for some odd reason these APIs are almost exclusively used in iframes without the allowfullscreen attribute.

[PhistucK]

Correction -

You mean <iframe allowfullscreen>.

So just to verify -

1. Clicking on the full screen button in standard video controls will still work, right?

2. Will this break all of the iFrame embedded YouTube (or any other video service) iFrames in terms of going full screen using the YouTube video controls?

If the answer to 1 is "yes", great.

If the answer to 2 is also "yes", this will break the user experience on the web and should be strongly evangelized first somehow (unless searching the internal Google index show very few results for such practice).

For example -

http://israblog.nana10.co.il/blogread.asp?blog=820574&blogcode=14305830

I hardly believe the author of the post deliberately removed the allowfullscreen attribute.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

On Sat, Apr 4, 2015 at 1:08 AM, PhistucK <phis...@gmail.com> wrote:
>
> Correction -
> You mean <iframe allowfullscreen>.

Correct.

> So just to verify -
> 1. Clicking on the full screen button in standard video controls will still work, right?

Yes, although I don't know how often that exemption comes into play, I
don't intent to change it.

> 2. Will this break all of the iFrame embedded YouTube (or any other video service) iFrames in terms of going full screen using the YouTube video controls?
>
> If the answer to 1 is "yes", great.
> If the answer to 2 is also "yes", this will break the user experience on the web and should be strongly evangelized first somehow (unless searching the internal Google index show very few results for such practice).
> For example -
> http://israblog.nana10.co.il/blogread.asp?blog=820574&blogcode=14305830
> I hardly believe the author of the post deliberately removed the allowfullscreen attribute.

If you search in the sources of
http://israblog.nana10.co.il/blogread.asp?blog=820574&blogcode=14305830
you will find no case-insensitive match for "enterfullscreen", so the
code path in question cannot be reached. When you get the HTML5
player, fullscreen simply does not work. It does with Flash, but
that's via some other API.

More generally, any video player with custom controls that preserves
its custom controls in fullscreen cannot be affected, because the
video element cannot be the fullscreen element in this case.

Also, any site that depends on this behavior cannot go fullscreen in
any non-WebKit browser.

Philip

[Chris Harrelson]

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Correction: in all use counter numbers, there's a zero too many. Check the graphs to see, but the maximum breakage ought to be 0.006%, but likely lower as speculated in the original message.

Philip

[p...@google.com]

LGTM

[Dimitri Glazkov]

LGTMX.

:DG<

[m...@brad.is]

Will HTMLVideoElement.webkitSupportsFullscreen return false when the allowfullscreen attribute is not present? We (Vimeo) fall back to the old API so that we can have a working full screen (with native controls) for sites that modify the embed code that we provide to users (it seems that there are some CMSes that remove the attribute no matter what).

If you are removing the exemption for sites, I think you should also remove it from the standard video controls as well.

[Philip Jägenstedt]

On Thu, May 28, 2015 at 5:54 PM,  <m...@brad.is> wrote:
> Will HTMLVideoElement.webkitSupportsFullscreen return false when the
> allowfullscreen attribute is not present? We (Vimeo) fall back to the old
> API so that we can have a working full screen (with native controls) for
> sites that modify the embed code that we provide to users (it seems that
> there are some CMSes that remove the attribute no matter what).

Thanks for letting us know about this problem, Brad!

Unfortunately, HTMLVideoElement.webkitSupportsFullscreen doesn't include the allowfullscreen check. As its deprecation message states, "its value is true if the video is loaded," which isn't very useful. I've been tempted a few times to make it essentially an alias of Document.webkitFullscreenEnabled, but it's not without risk, as webkitEnterFullscreen() throws an exception when webkitFullscreenEnabled is false, while the other APIs just fire a webkitfullscreenerror event.

You could of course also check document.webkitFullscreenEnabled, but do you intend to continue to rely on this fallback in WebKit even after it's gone from Blink? If so you have no way to feature detect the change, and I assume you want to remove the fullscreen button when it will not work.

A conservative change would be to include the allowfullscreen check in webkitSupportsFullscreen, but to stop ever throwing exceptions in webkitEnterFullscreen(). Would that solve the problem for you?

> If you are removing the exemption for sites, I think you should also remove
> it from the standard video controls as well.

I agree, the native controls shouldn't have any powers that sites don't have. I was planning to wait until this first change reached the stable channel to see what happens to the usage, but perhaps that wasn't so great. I'm leaning towards reverting the change for M44 and trying again with the exemption removed for all cases.

Please let us know if you need extra time to reach out to your embedders, or anything like that.

Philip

[m...@brad.is]

Hi Philip,

We added some metrics to our player and it looks like ~33% of plays from embeds don't have full screen enabled (checking via the latest api). Going to do some more digging to see where those embeds are.

You could of course also check document.webkitFullscreenEnabled, but do you intend to continue to rely on this fallback in WebKit even after it's gone from Blink? If so you have no way to feature detect the change, and I assume you want to remove the fullscreen button when it will not work.

Ultimately, we'd like to still be able to use the old api as a fallback in WebKit. If we have to we can do a User Agent check, but obviously it would be much better to be able to do a feature detect.

 

A conservative change would be to include the allowfullscreen check in webkitSupportsFullscreen, but to stop ever throwing exceptions in webkitEnterFullscreen(). Would that solve the problem for you?

I think it would since we would be able to rely on the webkitSupportsFullscreen property everywhere. I don't think the exception stuff would matter for us.

 

Please let us know if you need extra time to reach out to your embedders, or anything like that.

It would be really helpful to hold this change back a little so we can come up with a plan (either reaching out to embedders or changing player behavior).

- Brad 

[Philip Jägenstedt]

API owners, here's a new plan to get rid of the allowfullscreen exemption in all cases:

1. Revert the recent change to the web-exposed API and merge that to M44.

2. Deprecate the exemption for M45, giving Vimeo and others something to point at when reaching out to embedders.

3. In M46, remove the exemption for both the web-exposed API and <video controls>, change webkitSupportsFullscreen to include document.fullscreenEnabled as part of its definition and stop ever throwing exceptions in webkitEnterFullscreen(), instead firing a webkitfullscreenerror event as is already done for some other error cases.

I don't think this warrants a new intent, but if someone could sanity-check the plan that would be great.

Brad, this would move the removal from M44 to M46, giving you roughly three months extra, and the webkitSupportsFullscreen change allows you to feature detect the change. What do you think?

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[m...@brad.is]

That would be great! The extra time is much appreciated.

- Brad

[Matt Falkenhagen]

2015-06-04 20:42 GMT+09:00 Philip Jägenstedt <phi...@opera.com>:

API owners, here's a new plan to get rid of the allowfullscreen exemption in all cases:

1. Revert the recent change to the web-exposed API and merge that to M44.

2. Deprecate the exemption for M45, giving Vimeo and others something to point at when reaching out to embedders.

3. In M46, remove the exemption for both the web-exposed API and <video controls>, change webkitSupportsFullscreen to include document.fullscreenEnabled as part of its definition and stop ever throwing exceptions in webkitEnterFullscreen(), instead firing a webkitfullscreenerror event as is already done for some other error cases.

Hey, just want to make sure I understand. Vimeo falls back to the "old API" (which I think means <video controls>) to deal with sites that embed Vimeo using iframes without the allowfullscreen attribute. I gather this fallback is meant for browsers other than Blink ones, since until recently we had the exemption for webkitEnterFullscreen() on <video> elements.

Does this mean in other browsers <video controls> is exempt from the allowfullscreen check? Is it still OK for us to remove it?

[Philip Jägenstedt]

On Mon, Jun 8, 2015 at 5:34 AM, Matt Falkenhagen <fal...@chromium.org> wrote:

2015-06-04 20:42 GMT+09:00 Philip Jägenstedt <phi...@opera.com>:

API owners, here's a new plan to get rid of the allowfullscreen exemption in all cases:

1. Revert the recent change to the web-exposed API and merge that to M44.

2. Deprecate the exemption for M45, giving Vimeo and others something to point at when reaching out to embedders.

3. In M46, remove the exemption for both the web-exposed API and <video controls>, change webkitSupportsFullscreen to include document.fullscreenEnabled as part of its definition and stop ever throwing exceptions in webkitEnterFullscreen(), instead firing a webkitfullscreenerror event as is already done for some other error cases.

Hey, just want to make sure I understand. Vimeo falls back to the "old API" (which I think means <video controls>) to deal with sites that embed Vimeo using iframes without the allowfullscreen attribute. I gather this fallback is meant for browsers other than Blink ones, since until recently we had the exemption for webkitEnterFullscreen() on <video> elements.

Does this mean in other browsers <video controls> is exempt from the allowfullscreen check? Is it still OK for us to remove it?

This isn't quite correct. The change that created trouble for Vimeo was in the HTMLVideoElement.webkitEnterFullscreen() API, which was made to respect the same <iframe allowfullscreen> checks as Element.webkitRequestFullscreen() and the still-unshipped Element.requestFullscreen(). There were no changes to <video controls>, the fullscreen button would still bypass the checks.

I haven't seen the code, but something like this would have worked before the changed in WebKit and Blink:

if (video.requestFullscreen && document.fullscreenEnabled)
    video.requestFullscreen();

else if (video.webkitRequestFullscreen && document.webkitFullscreenEnabled)
    video.webkitRequestFullscreen();

else if (video.webkitEnterFullscreen && video.webkitSupportsFullscreen)
    video.webkitEnterFullscreen();

In the new plan, webkitSupportsFullscreen would return false. <video controls> would also play by the same rules, to avoid a situation where people try to style video::-webkit-media-controls-fullscreen-button as their own, make it huge and opacity:0 or other weird things. I believe this to be OK as the total "usage" of the exemption is low:

https://www.chromestatus.com/metrics/feature/timeline/popularity/485

Philip

[Philip Jägenstedt]

These changes have now been made:

https://codereview.chromium.org/1237133002

https://codereview.chromium.org/1240573005

Brad, and anyone else finding this thread, if you run into any issues, please let me know!

If it's smooth sailing, the allowfullscreen exemption will be gone entirely with M46.

Philip