Re: FPWD of Pointer Lock 2.0

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