Re: FPWD of Pointer Lock 2.0

Also, Keyboard Lock is a potential future solution for fullscreen
applications that want to handle ESC presses.

On Fri, Apr 28, 2017 at 9:59 AM, Vincent Scheib <> 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 <> 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 <> 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]
>>> [2]
>>> --
>>> @LeonieWatson Carpe diem

Received on Friday, 28 April 2017 17:03:09 UTC