Request Fullscreen take additional options

[dtapuska]

There are multiple uses of fullscreen, videos, gaming, etc. Sometimes an app may wish to just be transient full screen and want to just hide the status and URL bar.

Does it make sense to augment requestFullScreen with a dictionary so that applications can possibly not set

This can be done in native apps on Android by not specifying SYSTEM_UI_FLAG_HIDE_NAVIGATION

As well iOS has some APIs such as hidesBottomBarWhenPushed and prefersstatusbarhidden

[annevk]

Maybe, if we do anything here we should reconcile it a bit with window.open() perhaps.

[upsuper]

I don't think I fully understand what you want here.

Fullscreen means making the content take the whole screen area for it to display, and having UI hidden is an requirement for that to happen. But it seems you are proposing just hide the UI stuff?

Native apps on mobile system are kind of different, because those apps almost always already take the majority of the viewport, and thus hiding the system bars really means it's taking the whole screen. However, on desktop platforms, there are browser UI, as well as system UI, and browser may not take the whole desktop area from the beginning (when they are not maximized).

So it is unclear to me what you really want from that analogy.

[dtapuska]

A page may wish to go fullscreen but allow an app to go back easily. On devices with physical buttons for back/home it is easy but on pages that have overlays for that it may be harder for the user to detect how to go back. So I'm proposing a property like prefersNavigationBar which would not set the HIDE_NAVIGATION flag.

Samsung's browser always does this; it never hides the navigation bar however Chrome does. So I'm not certain how we can reconcile the default.

[foolip]

@gombos @rwlbuis @winstonchen, would you happen to know a good contact at Samsung to discuss this? Is this behavior you think would make sense for web developers to be able to control?

[winstonchen]

@dtapuska In response to your comment, "Samsung's browser always does this; it never hides the navigation bar...", Samsung Internet auto hides the navigation in some scenarios (ie. videos).

@foolip We will get back to you on your questions.

[dtapuska]

@winstonchen Yes I saw this and should have been more descriptive. Fundamentally the webpage has the best knowledge of whether it is a immersive experience or not and that is what this request for options is about.

[foolip]

Screenshots of Chrome and Samsung Internet showing the difference would be super helpful :)

[winstonchen]

From Samsung Internet. First is from a video. Second is from http://qnimate.com/full-screen-api-tutorial-with-demo/

[winstonchen]

From Chome. First is video, second is the full screen demo from above.

[foolip]

Aha, so it comes down do whether soft keys are visible? I guess controlling the status bar at the top is also something that native apps can do?

While coming up with terminology that makes sense across devices is going to be tricky, I think it makes very good sense that the web platform should be able to do this.

@jernoble, are there similar choices made for Safari's fullscreen on iOS, that could be influenced by the web page with an options dictionary of some description?

[jernoble]

@foolip, yes a native app on iOS can choose whether the status bar is visible (and what style the status bar takes on) during a presentation. The only fullscreen mode available on iOS Safari is the

[jernoble]

@foolip

While coming up with terminology that makes sense across devices is going to be tricky, I think it makes very good sense that the web platform should be able to do this.

I tend to disagree. I personally would be very concerned that a web page would be able to present itself in fullscreen mode and disable only affordance (soft keys) which allow the user to switch apps.

[foolip]

@jernoble

The only fullscreen mode available on iOS Safari is the fullscreen mode, so it's not really relevant here; Safari will always display the status bar and fullscreen media controls in that case.

Is the video case special, or do you mean that even with randomElement.webkitRequestFullscreen(), the status bar will always be visible?

I personally would be very concerned that a web page would be able to present itself in fullscreen mode and disable only affordance (soft keys) which allow the user to switch apps.

As you can tell from the screenshots, different Android browsers have gone with different behavior here, and it sounds like Safari iOS is "always display", so yeah, product teams have disagreed about this. (I wasn't aware of this difference at all before this thread, so have no background about Chrome's behavior.)

Whatever the default is, a way to get the other behavior could make sense:

• If no soft keys are shown by default, make them visible (uncontroversial, I presume).
• If they are, hide them, but perhaps only if the user has jumped through a number of hoops, probably browser-specific, perhaps something like the web app being "installed".

Whether any browser maker is in the second category I don't know, and certainly if the product decision is to always show certain bits of UI no matter what, then those options become meaningless to implement for those browsers. Is that the case for Safari iOS?

Samsung folks, what would you like?

[jernoble]

@foolip

Is the video case special, or do you mean that even with randomElement.webkitRequestFullscreen(), the status bar will always be visible?

I mean that iOS Safari doesn't support the "Fullscreen API" specification; the only fullscreen mode available is the old, unspecified HTMLVideoElement.webkitEnterFullscreen() one, that takes a <video> element into a fullscreen mode and adds native media controls (regardless of the controls attribute).

If no soft keys are shown by default, make them visible (uncontroversial, I presume).

Indeed.

If they are, hide them, but perhaps only if the user has jumped through a number of hoops, probably browser-specific, perhaps something like the web app being "installed".

Indeed as well.