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

Reply via email to