W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] api for fullscreen()

From: Brian Campbell <lambda@continuation.org>
Date: Wed, 3 Feb 2010 23:18:28 -0500
Message-ID: <F053E4F4-6B17-4528-9697-E8E1CCCA84E6@continuation.org>
On Feb 3, 2010, at 7:19 PM, Smylers wrote:

> Brian Campbell writes:
> 
>>> As I understand it, the risk with full-screen view is that a
>>> malicous site may spoof browser chrome, such as the URL bar, thereby
>>> tricking a user who isn't aware the site is full-screen.
>> 
>> This is addressing a different scenario; not malicious sites per-se,
>> but sites that insist on being displayed full screen.
> 
> OK.  That's 'merely' an annoyance, not a security threat.  There are
> lots of ways authors can be obnoxious if they choose; I'm not sure it's
> desirable, or even possible, to outlaw them.

Annoyances can turn into security threats if they train the user to click through security questions without thinking.

And actually, this can be a security issue as well. A malicious site could entice the user by offering some sort of desirable content (a movie or TV show, porn, a game), but only if the user allows it to go fullscreen with keyboard access. It could then wait until the user has been idle for a bit, and display something that looks like a standard login screen for the operating system in question. The user may then be enticed to enter their password without realizing it's still the full-screen site they were using and not a real login screen.

As ROC points out, it may be impossible to completely avoid a malicious site detecting whether you are fullscreen, as it can detect when the content is at one of the standard screen sizes; but we can make it a bit more difficult, and less likely that the user will be used to sites that require full screen, by providing the user an easy way to display "full screen" content in a window.

>> My boss was very insistent about content being displayed full screen,
>> to make the experience more immersive and reduce distractions ...
>> "Please press the button to enter full-screen mode and start the
>> program", and the program would not start until full-screen mode was
>> entered. I could imagine games, and other content doing the same as
>> well.
>> 
>> I think that this behavior is fairly user hostile, however.
> 
> In general user-agents are allowed to display content in anyway that a
> user has configured them to do, regardless of what the spec gives as the
> normal behaviour.

Yes. As I said, most of this is a UA issue, not a spec issue. I just want to encourage a usage that does not wind up with content locked behind requiring you to enter an actual full screen mode.

>> If a user wishes to view content scaled up to fill the window, without
>> the distractions of navigational links, comments, descriptions, and so
>> on, they don't usually have a way to do this. If it were possible to
>> use the full-screen button, but deny permission to actually go full
>> screen, and have that simply display the content in the full window
>> exactly as if it were full screen, it would give the users more
>> control over how they view the content.
> 
> I've seen Firefox options (possibly in an extension) which allow users
> to tweak which toolbars and the like are still displayed when in
> full-screen view.
> 
> If a browser (or an extension) wished to implement full-screen view as
> still having borders, the title bar, status bar, and so on then it
> could.  And there's nothing an author could do about it.

Of course. Obviously, the UA gets the final say on how the content is displayed. I just want to encourage the UAs to have a mode that tells the application it's in fullscreen mode even if it really is not, and have that mode be easy to get into for the majority of users (thus, not depend on an extension or obscure configuration somewhere).

>> Content authors should not be able to force fullscreen mode on users,
>> however, so I think it would be best if the spec allows UAs to send
>> the fullscreen event and set the fullscreen pseudoclass even if the
>> content is not actually filling the entire screen.
> 
> To say that slightly differently: authors can dictate that certain
> output is only displayed when in full-screen view; but they have no
> control how full-screen view looks for a particular user and user-agent.

Yes, exactly.

>> All the spec would have to say to cover all of the possible
>> implementations is that the fullscreen events may be sent even if the
>> content isn't actually filling an entire screen,
> 
> Allowing that behaviour is entirely reasonable.  Though I think it
> should be covered by a more general statement that user-agents may
> display things however they want if so-configured, rather than just
> stating it for this particular narrow case.

Well, user agents may display things however they want, but I think it's worth pointing out that the events may not correspond to the time that the user actually gives permission to enter full screen mode, in those cases in which permission is required. Instead, content may be scaled to the full window and the events sent as soon as the button is pushed, and then the content resized to the actual full screen once permission has been granted.

-- Brian
Received on Wednesday, 3 February 2010 20:18:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC