fullscreen

fullscreen copied to clipboard

I'd like the spec to allow a page to call requestFullscreen() on initial load.

One of the use case is slide show: slide shows ususally work best in fullscreen mode, however if a user click a link/button to navigate to a slide show page, he/she still need one more click to enter fullscreen mode. If requestFullscreen() were allowed on initial load (maybe in DOMContentLoaded and load events), the user expericence would be more seamless.

I'm aware of the security concern of the current spec. I think there are several solutions:

1. A UI to alert user that the page has entered fullscreen mode and allow user to quit fullscreen. It seems most UAs already have such UI.
2. Add opt-in attibute and parameter to <a> and window.open() to allow fullscreen on initial load. E.g. <a allowfullscreen href="link_to_a_slide">, window.open("link_to_a_slide", "", "allowfullscreen").
3. Apply same origin rule. Fullscreen on initial load may be only allowed if the load was triggered by a page in the same origin.

I prefer to have only 1. What do you think?

I would probably be against allowing requestFullscreen() inside DOMContentLoaded or load, because timing of those events can be controlled by websites.

I think the purpose of the current mitigations is to make users see reaction immediately after their input, so that they realize the relationship between the action and the outcome. However, that doesn't work for these two events.

I guess you misunderstand the security concern for this spec. The main concern is we don't want websites to be able to jump into fullscreen in an unexpected way for users. Whether the opener page can control is somehow less concerning.

For your specific use case, I think what may make sense is to integrate the slide show page in the current page, and request fullscreen in the first click, then load slides into the fullscreen container.

Thanks for the explanation!

Do you mean "integrate" by "embed the slides page inside an iframe"? This may work in some cases, but not if the current page has its UI design restriction, or not under the control of users/authors (e.g. forums, blogs, and webmails).

If the timing of DOMContentLoaded and load is a problem, how about restrict requestFullscreen() without user interaction to first 3 seconds after navigationStart? I think this behavior more or less "make users see reaction immediately after their input".

That would probably make it pretty unreliable. In some network environment, time between navigationStart and responseStart could be seconds, right?

Also navigation could be triggered by script as well. This is easy to solve, though, via requiring a user-initated navigation for it.

Right, but I think it's an acceptable limitation. If the network is slow, users can not expect seamless experience anyway.

@duanyao, was there something you were trying to build when you ran into this? The "if a user click a link/button to navigate to a slide show page, he/she still need one more click to enter fullscreen mode" issue I think can be solved without allowing requestFullscreen() in the load of a new document. Instead, when you click, fullscreen a div (perhaps with a spinner) and then populate it with an iframe with the slide show. Or is the problem that the iframe is a cross-origin service and that there's no way to start it directly in the present mode?

Yes. My team developed a HTML5 presentation editor, and the presentations try to request full screen on loading. Currently only works in Firefox when full-screen-api.allow-trusted-requests-only is set to false (we don't recommend users to set this, of cause).

We want the output presentation docs can be hosted in any site, and can be linked to from any site with minimum efforts. Fullscreening a iframe to embed the presentation could work sometimes, but has limitations:

• Need some programming on the embedding sites, instead of a simple <a>.
• Hard dependency on the embedded docs. What if a embedded doc is replaced in future with a doc that doesn't need full screen? The embedding page also need to inform the embedded doc when it enter/exit full screen, and the protocol (maybe via postMessage) is also a hard dependency.
• Users have difficulty to bookmark the embedded docs.
• Consumes more RAM, because the embedding page is still there although not visible when full screened.
• Looks strange if the embedded docs fail to load (404 etc.).

So I still think it's better to simply allow requestFullscreen() within navigationStart + N sec if the navigation is trigger by user action.

If what you want is that, when user clicks your link anywhere, the page opens in fullscreen directly, I would pretty much be against this idea. I don't believe user would desire this kind of behavior, as it would break their normal expectation that clicking a link opens a page. I would consider it annoying that a page enters fullscreen unexpectedly.

Also this function would still be very broken, because user may open the link in background tab, in which case fullscreen should not work anyway. Also many websites nowadays insert an intermediate page to warn users that they are leaving the current site, which would prevent the auto-fullscreen from happening as well.

Allowing any page to go fullscreen on initial load is more than would be required to solve the use case @duanyao describes I think. It's simpler than other solutions we can come up with, but probably too simple in that no user gesture at all is required.

Within an origin a site could change the URL and go fullscreen by using history.pushState and requestFullscreen, so in principle there's no reason why one origin shouldn't be able to collaborate with another to achieve the same thing.

@duanyao, even with the drawbacks you describe, have you tried to implement the fullscreen+iframe solution with the collaboration of the embedder? And what are the downsides of just providing an iframs snippet that sites can embed, and having the fullscreen button in the iframe? That's how YouTube does it, at least.

Allowing any page to go fullscreen on initial load is more than would be required to solve the use case @duanyao describes I think. It's simpler than other solutions we can come up with, but probably too simple in that no user gesture at all is required.

I've raised this issue before, and I think it should be possible to restrict it to be only triggered by a user-originated navigation (and within one or two seconds). But that's probably restrictive enough so that it is almost useless.

@upsuper

I don't believe user would desire this kind of behavior, as it would break their normal expectation that clicking a link opens a page. I would consider it annoying that a page enters fullscreen unexpectedly.

I would argue that "normal expectation" is nearly nonexistent these days: (1) normal users usually can't tell a block on a page is a link or a button or something else, because authors can (and usually do) style it arbitrarily. (2) even for links, the behavior is already unpredictable: think about target='_blank', download attribute, and onclick handler.

With current fullscreen spec and implementation, a page can already enter fullscreen somewhat unexpectedly -- click on an arbitrary point on a page can trigger fullscreen. My suggestion still requires same "trusted events" to trigger fullscreen, how is it significantly more unexpected?

The linking page could say "view the presentation (would fullscreen automatically)" on the link/button if it want to be explicit. I also suggested <a allowfullscreen> to require opt-in, so the linking page can also put a check box to allow users to disable it.

UAs could also provide an option to disable "fullscreen on loading" globally.

Also this function would still be very broken, because user may open the link in background tab, in which case fullscreen should not work anyway.

I think this is a reasonable case to disable fullscreen on loading.

Also many websites nowadays insert an intermediate page to warn users that they are leaving the current site, which would prevent the auto-fullscreen from happening as well.

I'm not sure how such intermediate page works in your mind, but if it requires a click to confirm, it should not prevent auto-fullscreen. Anyway, I think the linking sites could have the right to allow or disable potentially fullscreen link. Even if I choose the iframe way, the embedder need to explicitly set allowfullscreen to allow fullscreen.

@foolip

Within an origin a site could change the URL and go fullscreen by using history.pushState and requestFullscreen, so in principle there's no reason why one origin shouldn't be able to collaborate with another to achieve the same thing.

Of cause they can collaborate, but one of the principle of software engineering is loose coupling, right? Collaboration means if the implementation of the embedded page changed, all embedding pages may also need to change.

even with the drawbacks you describe, have you tried to implement the fullscreen+iframe solution with the collaboration of the embedder?

No.

And what are the downsides of just providing an iframs snippet that sites can embed, and having the fullscreen button in the iframe? That's how YouTube does it, at least.

This is already possible with our presentation -- we do have a fullscreen button on the tool bar of the presentation. The downside is, unlike videos, presentations can not be scaled down too much, so the impact on the UI design of the embedding page is significant. It is also difficult to bookmark an iframe, as I said before.

With current fullscreen spec and implementation, a page can already enter fullscreen somewhat unexpectedly -- click on an arbitrary point on a page can trigger fullscreen. My suggestion still requires same "trusted events" to trigger fullscreen, how is it significantly more unexpected?

That usually involves explicit button for fullscreen, and user would consider websites not showing that intend unfriendly. However you are proposing that a random link can go fullscreen, which would affect the experience of the referer page.

The linking page could say "view the presentation (would fullscreen automatically)" on the link/button if it want to be explicit. I also suggested to require opt-in, so the linking page can also put a check box to allow users to disable it.

You wanted to make it just a link so that it can be put everywhere. But an additional attribute sounds like more than that... I guess requiring linking page to explicit grant the auto-fullscreen behavior may resolve my concern above, but I don't see why this is much better than embedding an iframe. Does it much harder to write <iframe src="your-presentation-page.html" allowfullscreen></iframe> than <a href="your-presentation-page.html" allowfullscreen>Link (fullscreen)</a>?

I'm not sure how such intermediate page works in your mind, but if it requires a click to confirm, it should not prevent auto-fullscreen.

Most sites do not require a click, they just force you to see that page for several seconds and then redirect. If the embedder needs to explicit allow fullscreen, then I agree this isn't an issue.

The iframe solution is not harder to write than <a allowfullscreen>, but they are different in many aspects, and my conclusion is that it is usually not always a viable alternative.

• iframe is hard to bookmark.
• iframe impacts the layout of the embedding page (takes much more screen real estate than <a>). UI designer of the embedding page may feel unconformable with this.
• Embedding page is coupled with the embedded page. For example, the size of the iframe has to be specified by the embedding page, which means the size of the embedded page can't be changed easily in future.
• iframe is a larger attack surface than link. Many sites may forbid or filter iframe in user generated content, but I guess <a allowfullscreen> is much less a concern. Sites allow iframe may(and should) use sandbox="allow-scripts" to secure it, however this would block Flash, localStorage, and XHR/fetch etc, which we are using or may use in future.
• iframe consumes much more RAM than <a>, especially for complicated pages like presentations. A page may not afford to embed multiple of them.

I discussed with @annevk on IRC today about the usecase here, and we agree that it seems reasonable to add a fullscreen attribute to <a> and/or add a fullscreen parameter to window.open, so that the new page is open in fullscreen directly.

This is a bit different from the proposal here, though, that they would make fullscreen request for the new page directly, rather than relying on the new page itself to request fullscreen. This can avoid depends on timing of server's responsing.

@annevk pointed out that the difficulty here would be that, requesting fullscreen without an element is a new primitive, which needs some more thinking and discussion.

Thanks for update! I think <a fullscreen> could also fulfill our use case. It could be equivlant to requesting fullscreen on the body element of the new page, so it doesn't have to be a new primitive.

However, I think this solution has a drawback: if the new page doesn't require fullscreen by chance, the result can be awkward. E.g. the presentation was removed, so the user get a fullscreen'ed 404 page; or the author decided to replace the presentation with a normal airticle later on.

It could be equivlant to requesting fullscreen on the body element of the new page, so it doesn't have to be a new primitive.

It couldn't. When a new window opens, it synchronously opens an about:blank, then navigates to the url specified if any. No element presents when the window is opened would survive after the navigation.

So the main motivation of <a fullscreen> is that the new page should enter fullscreen synchronously to avoid the complication of defered requestFullscreen(), right? Then the problem is that the new page can't opt-out fullscreen -- I have no idea how this can be solved.

Right. And yes, the new page can't opt-out, because its opener ask it to be in fullscreen. It can, though, exit fullscreen when it wants.

Likewise, window opened by window.open cannot opt-out any feature specified in the parameter, document opened by <a target="xxx"> have no choice on where it would be put.

Window features are also not mutable to normal web pages, so it's consistant, but fullscreen has always been under the control of web pages. If the new page is an error page (4xx, 5xx), or is redirected to the login page, it wouldn't bother to exit fullscreen. Additonally, if the new page whose layout was not designed for fullscreen is forced to enter fullscreen, its layout may break.

Error page would be an issue, but page not designed for fullscreen would not be broken. It would just be shown as if you enter fullscreen mode.

There are fullscreen related rules in UA stylesheets, e.g. in Chrome 54:

:-webkit-full-screen {
    background-color: white;
    z-index: 2147483647;
}

Firefox 52:

*|*:fullscreen:not(:root) {
  position: fixed !important;
  top: 0 !important;
  left: 0 !important;
  right: 0 !important;
  bottom: 0 !important;
  width: 100% !important;
  height: 100% !important;
  margin: 0 !important;
  min-width: 0 !important;
  max-width: none !important;
  min-height: 0 !important;
  max-height: none !important;
  box-sizing: border-box !important;
  object-fit: contain;
  transform: none !important;
}

In most cases this will not be a problem, but there are still chances.

See the UA stylesheet required by the spec. No additional style should be applied to the fullscreen element if it is the root element.

Ah, right. I thought the UA stylesheet in the spec was not madatory.