On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser <s...@me.com> wrote: > We have been discussing a more general fullscreen API that lets you take the > page fullscreen (perhaps with the ability to focus on a single element), as > Maciej mentions. We have not decided on a final form for this API, nor have > we resolved whether it's possible to do some nice transition between the two > modes. We have talked at some length about the security issues. > > Input on what people would like from this API is welcome, as are ideas on how > the transitions should work. > > 1) Should be convenient for authors to make any element in a page display > fullscreen > 2) Should support in-page activation UI for discoverability > 3) Should support changing the layout of the element when you enter/exit > fullscreen mode. For example, authors probably want some controls to be fixed > size while other content fills the screen. > 4) Should accommodate potential UA security concerns, e.g. by allowing the > transition to fullscreen mode to happen asynchronously after the user has > confirmed permission > > *** WARNING: totally half-baked proposal ahead! *** > > New API for all elements: > void enterFullscreen(optional boolean enableKeys); > void exitFullscreen(); > boolean attribute supportsFullscreen; > boolean attribute displayingFullscreen; > "beginfullscreen" and "endfullscreen" events > > The enableKeys parameter to enterFullscreen is a hint to the UA that the > application would like to be able to receive arbitrary keyboard input. > Otherwise the UA is likely to disable alphanumeric keyboard input. If > enableKeys is specified, the UA might require more severe confirmation UI.
I'd like to start a discussion on steps that the UA may take to mitigate the risks of using the fullscreen API for phishing attacks. I'm not sure how much should be required of UAs in the spec, but I could imagine that steps that the UA could take may include some or all of the following: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. * disallow enterFullscreen() from a frame or iframe * show an animation as the window enters fullscreen so the user can see the transition taking place * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. * show an affordance to allow the user to exit fullscreen (e.g. a close button) when the user moves the mouse * make the location field available to the user so that they can see the URL even when in fullscreen * drop out of fullscreen if navigating to another page * if focussed on an element, drop out of fullscreen if that element is removed from the DOM * limit arbitrary keyboard input unless 'enableKeys' is true * disallow window.open etc. while in fullscreen I'm just not sure which of these would be requirements in the spec. Simon
