The HTML5 Fullscreen API is finally here! (OK, so it's been here for a while but hey, nobody told me).

When I first started learning about the new HTML FullScreen API, I found many articles referring to the "obvious" security risks of allowing keyboard input in fullscreen mode, but few cared to elaborate on this and left it to the reader to guess what these "obvious" risks were.

I do not consider those risks to be obvious at all, so I decided to write this article to explain and illustrate how a browser in fullscreen mode might be considered dangerous under certain circumstances.

Different browsers will deal with the security concerns in different ways - but the HTML5 Video Player at the top of this page should give you an idea of the kind of hack browser developers are expecting from malicious websites. And once you understand how it works, it is very unlikely you will ever become a victim of this type of password theft in the future.

Because any element can be made fullscreen (not just video) a malicious website could easily fool you into giving them your password details by using an image of your Operating System login screen with an HTML input text field on top.

If you click the button on the HTML5 Video Player at the top of this page, you can see just how convincing this might look when your browser is in fullscreen mode.

To address this problem, both Google Chrome and Mozilla Firefox issue warnings (see below) whenever RequestFullScreen is activated by a script. Chrome also disables keyboard input in fullscreen mode (with the exception of the Space, Return and Esc keys). By not disabling keyboard input, it would appear that Firefox have opted to put their trust in the intelligence of their users (or at least pin the blame on them if their passwords get stolen in this manner).

Strangely enough the warnings themselves do not actually prevent you from using either keyboard or mouse in fullscreen mode.

Firefox's approach is better for the web developer, but more dangerous to the user. However, their warning is by far the more noticable of the two, and less likely to be ignored by the majority of web users who are prone to clicking "Allow", "OK" or "Next" without even thinking about it.

In addition to the keyboard lock out, Chrome restricts setTimeout on a FullScreen event to no more than 1000 milliseconds, and Firefox has chosen to disable it altogether.

Importantly, the FullScreen API can only be fired by a mousedown or click event - and will not respond to a simulated click

Security concerns aside, there can be no doubt that the Fullscreen API is one of the most important developments in generic web technology to date. Unlike Apple's original FullScreen API draft for the iOS in Safari 5, the fullscreen event can be attached to ANY element, but it is of particular siginificance where HTML5 <video> is concerned. (Note: The video element is the only element that is automatically re-sized when fullscreen is active. But unlike Firefox, Chrome only does this if the target element itself is the video).

Up until now, the majority of web developers have held back from using HTML5 video as an alternative to Adobe Flash mainly because it lacked fullscreen support. Fullscreen-in-browser was always an option of course, but if Carlos the connector has muchos toolbars con browser, fullscreen could quite literally mean halfscreen, and that's just pants.

This fact, combined with the lack of cross-platform support (Microsoft added minimal HTML5 support in IE9, which included the new <video> element - but ONLY if you went out and bought Windows 7) has made HTML5 Video an almost unheard of technology outside of the web developing community.

As of writing, Mozilla Firefox(11+), Google Chrome(21+), Safari(5.1+) and Opera(12+) all support HTML5 Video and the Fullscreen API. (I have only tested with Firefox 17 and Chrome 23, so any script references I make here are based soley on my results with those browsers / versions).

All versions of Internet Explorer up to and including 10 have NO fullscreen support, and Microsoft have NO plans to implement it in the future. (But should anyone really care? I believe web developers have only themselves to blame for Internet Explorer's continued existence (and use) by coding extensive work-around solutions (different for each version!) despite it's countless flaws, inadequacies, and lack of support for anything new and wonderful that isn't designed by Microsoft - when they should have stopped supporting it years ago).

Requiring your visitors to download an advanced browser that will seriously enhance and speed up their internet experience is not something to shy away from! So why is nobody (and by nobody, I mean the entire web developing community) making a stand on this?!

Anyway, back to the Fullscreen API...

Disappointingly, the familiar browser-specific prefixes that have become all too (annoyingly) familiar since the release of CSS3 have managed to find their way into the Fullscreen API.

For those not familiar with CSS (it stands for "Cascading Style Sheets" and is the scripting language used to style web pages) - applying the new CSS3 transition style to an element should have been as simple as:

.transition_style{
	transform:rotate(180deg);
}

Instead, all of the major browsers wanted their own versions of the exact same feature, meaning that developers who want the style to work in every browser have to do something like this:

.transition_style{
	transform:rotate(180deg); /*-- W3C --*/
	-moz-transform:rotate(180deg); /*-- Mozilla Firefox --*/
	-webkit-transform:rotate(180deg); /*-- Chrome, Safari --*/
	-o-transform:rotate(180deg); /*-- Opera --*/
	-ms-transform:rotate(180deg); /*-- Internet Explorer --*/
	-khtml-transform:rotate(180deg); /*--  Konquerer? --*/
}

The same applies for almost every single CSS3 Style! The result? Code duplication on an EPIC scale, with no benefit to anyone.

So with the Fullscreen API, where the W3C propose document.RequestFullScreen() expect to use

• document.mozRequestFullScreen()
• document.webkitRequestFullScreen()
• document.oRequestFullScreen()

for Mozilla Firefox, Chrome/Safari and Opera respectively.

There is however one noticeable exception to this rule. For determining the current fullscreen state of the browser, webkit based browsers include an Is in the statement.

Webkit (Safari, Chrome): document.webkitIsFullScreen Gecko (Mozilla Firefox): document.mozFullScreen

There are even new psuedo CSS classes for automatically styling elements in their fullscreen state. At the time of writing, :-webkit-full-screen works with Chrome 23 and :-moz-full-screen works with Firefox 17.

The easiest way to be sure that your code will work in any browser that currently supports the FullScreen API, is to create an array of browser prefixes, check each one by using:
if(typeof document.[browser_prefix + CancelFullScreen] != 'undefined') and if you get a match, store the browser prefix to a variable. Then anytime you call a fullscreen function, just prepend it with that variable.

(And if you fail to get a match with any of them, you can assume that your visitor's browser does not support the FullScreen API, and implement your fallback solution - or just tell them to go away).

So, if you wanted to call document.RequestFullScreen, and the value stored in your variable was 'webkit', you would use: document[your_browser_prefix_variable + 'RequestFullScreen']() - which is the same as: document.webkitRequestFullScreen()

Just remember to make an exception to this rule for the document.FullScreen query, where webkit based browsers like Safari and Chrome require document.webkitIsFullScreen and not document.webkitFullScreen

Here is my simple cross-platform solution that I'm using for the video on this page:

//============================================================
// check fullscreen support for webkit, moz, o, ms, khtml
//============================================================
var fullscreen_browser_prefix = null;
var prefix_array = new Array('webkit', 'moz', 'o', 'ms', 'khtml');				
for(prefix in prefix_array){				
	if(typeof document[prefix_array[prefix] + 'CancelFullScreen'] != 'undefined'){
		fullscreen_browser_prefix = prefix_array[prefix];
		//---------------------------------------------
		// add fullscreen event listener to the DOM
		//---------------------------------------------
		document.addEventListener(fullscreen_browser_prefix + 'fullscreenchange', fullScreenEventHandler, true);
		break;
	}		
}				
if(typeof document.CancelFullScreen != 'undefined'){
	//------------------------------------------------------------------------------
	// W3C standard (no browser prefix) << why do none of the browsers use this?!
	//------------------------------------------------------------------------------
	document.addEventListener('fullscreenchange', fullScreenEventHandler, true);
	bsc.innerHTML = 'Your browser supports FullScreen API';
}
function fullScreenEventHandler(){
	//-----------------------------------------
	// FullScreen an element, for example...
	//-----------------------------------------
	document.getElementById('video')[fullscreen_browser_prefix] + 'RequestFullScreen']();
}