HTML5 Full Screen: Now in Firefox

Nothing looks good surrounded by junk. Or even if the junk looks nice, it can easily distract from what it surrounds.

Painters know this; many won't let anyone else else frame their paintings.

App designers know this too -- but web designers are a little out of luck, because the stupid browser shows its stupid controls and you can't control them and why can't I just make my beautiful site go full-screen?

Besides web design, web gaming also suffers from inability to force a fullscreen. (Orcs and scrollbars don't mix.)

Users can choose to fullscreen a site manually, of course -- but, especially for designers, that's not enough. (Users can choose to put great paintings in nice frames too, but no gallery designer would be happy with anything less than complete control.)

So, from the designer/gamer's point of view, app-controlled browser fullscreen would be great.

But from security's point of view, app-controlled browser fullscreen can be a real problem.

As Robert O'Callahan says:

Our biggest issue right now is how to make [fullscreening] secure. The perceived threat is a malicious page going full-screen and then displaying something that looks like the content of another site, say the user's bank, complete with false URL bar --- or the content of a native application or the operating system, for that matter.

Robert's full discussion (from this past August) is worth reading, along with the comments.

The larger discussion began in January 2010, and a complete Gecko FullScreenAPI proposal was on the table for some time -- complete with extensive notes on security.

Meanwhile, WebKit (used in Chrome) figured out its own fullscreen API last January -- mostly following Mozilla's proposal, though with a few exceptions.

But last week Firefox's own fullscreen browser API went live.

This is the culmination of long debate, and includes many security features designed to respond to common concerns. In particular, according to Mozilla's security documentation, Firefox won't grant fullscreen requests at all except when:

1. Running in a user-generated event handler (same code path as pop-up blocking).
2. Within the first second of running in a user-generated event handler.
3. When all ancestor iframes have the mozallowfullscreen attribute.
4. When there are no windowed plugins present (on non-MacOSX platforms).

Then, the user will be warned as much as possible-and-not-annoying:

1. [Firefox] dim[s] the <browser> element for the first 2s.
2. [Firefox] show[s] a warning message for the first 4s after entering full-screen.

And Firefox will exit fullscreen on a hair-trigger, whenever:

1. Keys not listed in https://wiki.mozilla.org/Gecko:FullScreenAPI#Proposed_Specification (e.g. alpha-numeric keys) are pressed (simulated events don't break us out of full-screen).
2. A windowed plugin is added to the document.
3. Navigation occurs.
4. Focus changes to another tab. (e.g. Ctrl+Tab / command+tab)
5. User hits Esc
6. User hits F11

Sounds good enough to me. (But then I really like fullscreen browser content.)

For implementation details, check out Chris Pearce's full announcement, which includes a Firefox-specific example (after you've downloaded the current Firefox nightly build), or a cross-browser demo (which works in newer Chrome stable releases too).