Re: FPWD of Pointer Lock 2.0

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