Re: FPWD of Pointer Lock 2.0

My proposal for today is to use other buttons. I'm aware of the common game
paradigm of ESC exiting games. I've played plenty of counter strike, ;) but
we also needed a reliable unlock gesture.

My implementation in Chrome does not re-show The ESC instructions when a
page calls exitPointerLock and then requestPointerLock again - specifically
to avoid the nuisance you mentioned.

Keyboard Lock, if it progresses, will offer applications & games the
ability to override taps to ESC key (the user agent will use a sustained
hold of ESC to force exit). See linked explainers and spec drafts here:
https://www.chromestatus.com/feature/5642959835889664


On Fri, Apr 28, 2017 at 10:41 AM, Florian Bösch <pyalot@gmail.com> wrote:

> ESC is actually a common key to trigger a menu in many games, and it
> usually does not mean exit fullscreen.
>
> On Fri, Apr 28, 2017 at 7:38 PM, Florian Bösch <pyalot@gmail.com> wrote:
>
>> On Fri, Apr 28, 2017 at 6:59 PM, Vincent Scheib <scheib@google.com>
>> wrote:
>>
>>> My suggestion is to use something other than ESC to exit pointer lock
>>> via javascript, and thus not exit fullscreen. E.g. the 'f' key, '~', space
>>> bar, 'q', etc.
>>>
>>
>> You cannot override ESC, and the UA informs the user that to regain his
>> cursor, he should press ESC. It's inevitable that the user will actually do
>> so, since he's told to do so. From an UX point of view, designing an info
>> box explaining to the user to avoid pressing ESC (and ignore that other
>> info box), because that may not be what he wants to do, and instead press
>> another key, while another info box is hovering on screen telling him to
>> press  ESC sounds really bad, but I'm not expert, so... why don't you ask
>> an UX expert how confusing that will be to a user?
>>
>>
>>> The reason ESC was specified to exit both was to satisfy concerns of
>>> users not knowing how to exit these features. The concept of stacking the
>>> permissions adds conceptual complexity.
>>>
>>> Essentially, we believed there would be many users confused by a page
>>> entering both fullscreen and pointer lock, wanting to get out, trying ESC
>>> and not having fullscreen exit. They barely understand that pointer lock
>>> was also entered and is now exited. They may not understand the difference
>>> between an application drawn cursor and the now visible system cursor. They
>>> may not think to keep repeating pressing ESC.
>>>
>>
>> Here's an example of a game (counter-strike) coming from a first-person
>> control to using a pointer based modal to operate a menu and then go back
>> to the first-person control: https://youtu.be/u8YbYBZtbAs?t=442 . The
>> menu is triggered by the key B. However counter-strike does not have to
>> deal with the fact that whenever a user returns from the menu to the
>> first-person view, that a black box is drawn over their viewport informing
>> the user to press ESC...
>>
>>
>>
>