Intent to Ship: Unprefixed Fullscreen API with FullscreenOptions

[Dave Tapuska]

Contact emails

dtap...@chromium.org

Explainer

Ship unprefixed version of requestFullscreen/exitFullscreen with FullscreenOptions.

Spec

https://fullscreen.spec.whatwg.org/

https://github.com/whatwg/fullscreen/pull/129

Tag Review was discussed in 2014. Minor changes to the API have occurred specifically around adding promises and event firing.

I have not filed a tag request for the Fullscreen Options and I consider this a minor addition.

Summary

Support the unprefix requestFullscreen API. Unprefixing this API has been a multi year effort and in Chrome 69 we will ship the fullscreen implementation using top layers. This was the main blocker in unprefixing the API. In Chrome 71 we'd like to ship the unprefixed version of the API.

At the same time we'd like to always show the navigation bar on Android devices by default. This matches the Samsung Browser UX and improves the user experience when exiting fullscreen mode on Android. webkitRequestFullscreen and webkitRequestFullScreen will continue to function as they do today. FullscreenOptions provides a mecahnism to request hiding the navigation bar.

Link to “Intent to Implement” blink-dev discussion

Fullscreen Options

Unprefixed fullscreen previous I2S

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

Interoperability and Compatibility

There is certainly some interoperability risk. Chrome 69 contains the implementation matching the current spec which derisks the shipping of this API. Edge failed to ship this API and it isn't clear what interoperability concerns were encountered.

Edge: In development (attempted shipping once)

Firefox: In development

Safari: No signals

Web developers: No signals

Ergonomics

None

Activation

None

Is this feature fully tested by web-platform-tests?

Yes

Entry on the feature dashboard

https://www.chromestatus.com/feature/6596356319739904

https://www.chromestatus.com/feature/5188650908254208

[PhistucK]

What is this "navigation bar"?

You mean the Chrome toolbar with the URL field? Or the Android status bar at the top?

(I always found it weird that it removes the status bar, is there going to be an option for either?)

☆PhistucK

--
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/CAHgVhZWpqL_YUTYqf_q-cVORYppgg4f2w51733WNwJt3d%3DcYQw%40mail.gmail.com.

[Dave Tapuska]

The navigation bar is the bottom bar on Android devices that performs, back, home, switch app functions. Some Android devices have physical space reserved. Others they are virtual.

dave.

[PhistucK]

Oh, yeah, forgot about that one. :)

I just revealed my low mobile usage. :P

☆PhistucK

[Mike West]

This looks like a thing we should do. One question inline:

On Thu, Aug 30, 2018 at 6:52 PM PhistucK <phis...@gmail.com> wrote:

Oh, yeah, forgot about that one. :)

I just revealed my low mobile usage. :P

☆PhistucK

On Thu, Aug 30, 2018 at 7:36 PM Dave Tapuska <dtap...@chromium.org> wrote:

The navigation bar is the bottom bar on Android devices that performs, back, home, switch app functions. Some Android devices have physical space reserved. Others they are virtual.

dave.

On Thu, Aug 30, 2018 at 12:26 PM PhistucK <phis...@gmail.com> wrote:

What is this "navigation bar"?

You mean the Chrome toolbar with the URL field? Or the Android status bar at the top?

(I always found it weird that it removes the status bar, is there going to be an option for either?)

☆PhistucK

On Mon, Aug 27, 2018 at 7:02 PM Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org

Explainer

Ship unprefixed version of requestFullscreen/exitFullscreen with FullscreenOptions.

Spec

https://fullscreen.spec.whatwg.org/

https://github.com/whatwg/fullscreen/pull/129

Anne from Mozilla left some comments on this PR which seem like they might change the interface a bit. Are y'all going to have this hammered out before shipping?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JSYW8Y9LoFhMime0%2BX53o%2B6Kkb%2B1M-1V%2BKRJEyKRCxBA%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Sep 4, 2018 at 3:09 PM Mike West <mk...@chromium.org> wrote:
> Anne from Mozilla left some comments on this PR which seem like they might change the interface a bit. Are y'all going to have this hammered out before shipping?

They shouldn't affect the API itself, just how it's defined. (I
proposed the IDL in the PR to Dave on IRC.)

Hope that helps,

Anne

[Dave Tapuska]

I believe it is hammered out (Anne and I worked together on the IDL) but will remain a PR until another browser vendor commits to it. But that shouldn't preclude Chrome from going first.

dave.

[Chris Harrelson]

Hi Dave,

You say:

"There is certainly some interoperability risk. Chrome 69 contains the implementation matching the current spec which derisks the shipping of this API."

Are you saying that the prefixed implementation in Chrome 69 is exactly the same as the proposed unprefixed one at this point? From reading the previous I2S it sounds like that that was the blocker the first time around.

If that is true, what other interoperability risk do you foresee? Just that Chrome would be the first browser launching an unprefixed API?

--

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/CAHgVhZXvobzHKwNyLgnOq3xe50kosNhevZeX21J015QgZZHtsg%40mail.gmail.com.

[Dave Tapuska]

Yes the prefixed version's implementation in M69 has been changed so that matches the unprefixed's current specification. This was the main issue in shipping the API previously. I believe the interop risk is that we are shipping a new API and that some websites feature detect for it because it briefly shipped in Edge. It isn't clear what interop issues Edge ran into that they unshipped it.

dave.

[Chris Harrelson]

I see, thanks for clarifying.

LGTM1!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZVgbZypgqg1ObYT4hGRMGyF4waN7rT5pg9pS5gaOGVoWw%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

This has been a long time coming, thank you Dave for moving this across the finishing line.

I've reviewed https://github.com/whatwg/fullscreen/pull/129 now and if there are no further comments I'll merge it this week together with a trivial test.

I believe that the web compat risk (regressions) is the main thing to worry about here. A known case that both Edge and Firefox have run into is video.js - infinite recursion with unprefixed Fullscreen API. I just tested the affected site and can confirm that it affects Chrome Canary with the unprefixed API enabled, showing "Maximum call stack size exceeded" in the console. I will dig in a bit and comment further on that bug.

However, I believe that the interop risk of not shipping this is significant, i.e. the risk that we'll never have a fullscreen API that works on all browsers. Getting this shipped is worth quite a lot in that regard.

I would not be surprised if this has to be reverted and relanded a few times as addition compat constraints are uncovered, but at this point I definitely support attempting to ship to learn more.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-YBrNLuamMO1TrOf2PpWiXW9DZs6Li4RzqqLop0APvNg%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-YBrNLuamMO1TrOf2PpWiXW9DZs6Li4RzqqLop0APvNg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Daniel Bratell]

Make that LGTM3 (Philip and I cross posted).

/Daniel

[Philip Jägenstedt]

LGTM22!

I did a bit more digging in https://github.com/webcompat/web-bugs/issues/2498#issuecomment-418429075, namely an httparchive search for 'Video.js v4.', which is in the header of the (minified) source for the affected video.js version. 1519 hits is more than I would have guessed. I've spot checked a few (~5) and couldn't find any that actually use video.js to play a video. Still, it does seem likely that some site will be affected and that it will only be noticed when a user tries to enter fullscreen.

Dave, if you spot this breakage in regressions, can you loop back here? At the very least we should then provide instructions for patching the old video.js in-place to fix the problem.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zotqaij5rbppqq%40cicero2.linkoping.osa.

[quanx...@gmail.com]

FYI, there is another major breakage we've identified that, with unprefixed Fullscreen API enabled, Youku, one of the largest video websites in China, cannot enter fullscreen anymore. See https://bugzilla.mozilla.org/show_bug.cgi?id=1440921#c6 for the analysis. But probably if Chrome ships the unprefixed API, they are more likely to fix their code promptly.

- Xidorn

[Dave Tapuska]

I've confirmed this is an issue with Chrome and is a flaw in their logic. I don't think this is a major issue as the site continues to function fine just when they enter fullscreen they prompt exit it again. This should be a minor fix to their logic and I hope that once we get this into canary, dev and beta channels then it will be fixed before we hit stable.

dave.

[Philip Jägenstedt]

Good news, after reaching out to folks at Alibaba they've confirmed they're aware of it and will fix it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZX-HErq%2BNM_tJ4nnb4MtzfKteGxo-u4_5oZV4OkoVFQew%40mail.gmail.com.