Re: FPWD of Pointer Lock 2.0

Also, Keyboard Lock is a potential future solution for fullscreen
applications that want to handle ESC presses.
https://www.chromestatus.com/feature/5642959835889664

On Fri, Apr 28, 2017 at 9:59 AM, Vincent Scheib <scheib@google.com> wrote:

> Thanks for the feedback Florian.
>
> 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.
>
> 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.
>
> On Fri, Apr 28, 2017 at 3:34 AM, Florian Bösch <pyalot@gmail.com> wrote:
>
>> I have just encountered an awkward usage scenario in a client project
>> where pointerlock is used in conjunction with fullscreen. I believe this
>> would be instructive to review to inform future spec-work.
>>
>> The usage scenario involves a WebGL "viewer" component that may operate
>> in different camera modes. Usually a fullscreen button is offered that sets
>> the container containing the canvas (and some UI elements) into fullscreen
>> mode.
>>
>> One of the camera modes offered is a first-person camera where
>> pointerlock is used to capture the mouse to control the viewpoint, this is
>> another button in the UI. When pointerlock is requested, the only way to
>> exit it is the ESC key (as implemented by the UA and which for good reason
>> cannot be overriden).
>>
>> If a user enters fullscreen and then activates first-person camera, the
>> ESC key throws the viewer component both out of fullscreen and out of
>> pointerlock.
>>
>> This is awkward because from the sequence of events leading up to being
>> in pointerlock/fullscreen does not indicate that the users intention was to
>> end both pointerlock and fullscreen. The viewer components UI can only be
>> operated if pointerlock is ended however, and so the user only gets to have
>> a choice of this pointerlock+fullscreen UI interaction:
>>
>>    1. enter fullscreen by clicking on the fullscreen button
>>    2. enter first-person view by clicking on the first-person camera
>>    button
>>    3. exit by ESC in order to click on the UI which ends both
>>    pointerlock and fullscreen (and ends first-person camera view mode because
>>    without pointerlock it's painful to use)
>>    4. can now interact with the UI
>>    5. enter fullscreen again by clicking on the fullscreen button
>>    6. enter first-person view again by clicking on the first-person
>>    camera button
>>
>> The workaround adopted in this instance was to assume that first-person
>> view, pointerlock and fullscreen are intended to be used together (which
>> probably more likely than not), and hence trigger all three together, such
>> that all three may be re-engaged once the user has pressed ESC to escape
>> all of them. This is not optimal by any stretch of the imagination.
>>
>> Many applications (particularly games) may wish to let the user interact
>> with UI elements (often represented by the DOM), while staying in
>> fullscreen, but may wish to offer pointerlock nevertheless. Emulating a
>> cursor is not desirable because it's not as smooth as native cursors,
>> cannot match the native cursors representation and has difficulty
>> synthesizing DOM events for full compatibility.
>>
>>
>> On Tue, Nov 22, 2016 at 9:55 AM, Léonie Watson <tink@tink.uk> wrote:
>>
>>> Hello WebPlat,
>>>
>>> With thanks to Vincent and Xiaoqian, the FPWD of Pointer Lock 2.0 has
>>> been published [1]. Comments and contributions from the WG are welcome [2].
>>>
>>> Changes from the Pointer Lock 1.0 Rec focus on Shadow DOM content, and
>>> are noted in the Status section of the 2.0 spec.
>>>
>>> Léonie.
>>> [1] https://www.w3.org/TR/2016/WD-pointerlock-2-20161122/
>>> [2] https://w3c.github.io/pointerlock/
>>> --
>>> @LeonieWatson tink.uk Carpe diem
>>>
>>>
>>
>