Over a million developers have joined DZone.

HTML5 Full Screen: Now in Firefox

DZone's Guide to

HTML5 Full Screen: Now in Firefox

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

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).

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}