> > > 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. >>> >> >> This seems overly complicated. I think it would suffice to simply show a >> dialog the first time a user wants to go fullscreen within a domain with an >> option to "remember this choice for this domain." Then the user won't have >> to jump through the hoops again when they return, but will still protect >> them from random websites going fullscreen and trying to phish things. This >> way blocking or restricting keyboard events isn't needed. >> > > Those kinds of dialogs are dangerous because users tend to just dismiss > them without reading. Passive (ignorable and asynchronous) confirmation > works better. > > The enableKeys option would let authors who don't need alphanumeric input > (video playback) go fullscreen with a low confirmation bar (perhaps none at > all, if the fullscreen request is in a click event handler). >
I know it's not the biggest concern right now, but I thought it's worth pointing out: on mobile touchscreen devices this hint does nothing as the site can spoof the keyboard as well. I don't see any harm in this hint, but I'd say the focus should be on ensuring it's clear to the user what's going on in either case.
