This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The pointer lock spec Working Draft 29 May 2012 is written specifying several requirements to enter mouse lock, and leaving user agents to add additional constraints to prevent nuisance and enforce security policies. Specifically the Element requestPointerLock method section [1] states "The user agent determines if pointer lock state will be entered" and the Security section [2] includes varying policies including 'A conservative approach' requiring user gestures and 'A full screen approach' requiring full screen. Initial implementations have added additional constraints beyond those explicitly listed in [1]. Firefox 14 introduced pointer lock requiring that fullscreen be entered and confirmed and that the pointer lock target match the fullscreen element. Chrome 22 introduced pointer lock with a more permissive policy, allowing pointer lock of any element after fullscreen has been confirmed. Chrome also permitted pointer lock outside of fullscreen if it was requested via a user gesture. Concern was raised in public-webapps discussion [3] that all user agents should use the same policy and that be incorporated into the specification. [1] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#methods [2] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#security [3] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
The goal of the specification should be to: 1) Provide a reliable API for developers with known behavior 2) Avoid UX issues around the usage of pointerlock insofar as the API should not be structured to promote bad UX itself or patterns of usage by developers that are bad UX 3) Provide safety measures impacting UX as little as possible to ensure that malicious behavior is kept at bay. Current implementations are currently not fulfilling #1, they are only partly fulfilling #2 and they may or may not fulfill #3. It is my belief that a thorough specification of the UX and Safety measures can be done, and that it would help vendors to arrive at consistent, usable and safe implementations without requiring them to have lengthy internal discussions about how to restrict pointerlock culminating in pointerlock behavior that would then be inconsistent between browsers. Section 8 of the specification lists some use-cases which are recommended not to be compromised such as: - Making it possible to seamlessly switch between pointerlock and releasing it - Making it possible to request pointerlock without requiring fullscreen at the same time - Making it possible for iframes to request pointerlock. An issue with current implementations is the requirement for fullscreen by one vendor in the form of only regarding pointerlock requests soonest in the fullscreenchange event, while another vendor does not impose such a restriction, yet does restrict requestPointerLock only to user interaction events. This is particularly bad since we are not dealing with differing APIs, but entirely differing behavior, that stands no hope of being wrapped, abstracted, monkey patched or otherwise glanced over. The abstraction of these decisions will fully leak trough to user-code.
(In reply to comment #1) I would propose assembling a repository of use cases/UX and attack vectors both including tests for each so the specification can use specific language to address these issues.
Let's wait for the outcome of Mozilla's security review [1]. It may find Chrome's policy [2] acceptable (possibly with minimal changes that Chrome could adapt to), and that could be added to the specification. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c16 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5
Would be good to know what all cancels pointer lock in Chrome. Does clicking anywhere outside the page's view port do it?
Also, while pointer is locked, is it possible to use JS to move the window which locked the pointer?
(In reply to comment #4) > Would be good to know what all cancels pointer lock in Chrome. > Does clicking anywhere outside the page's view port do it? It's hard to click outside the page's view when you have no mouse cursor. ;) No mouse gesture escapes. - ESC key. Normative from spec: - Any action which causes the browser tab to loose focus (such as alt-tab, ctrl-tab, windows key, mac key, a dialog pop-up). - Target element being removed from dom tree, and thus implicitly document removed or navigation. (In reply to comment #5) > Also, while pointer is locked, is it possible to use JS > to move the window which locked the pointer? It should be, no reason to specify that it should not that I can see.
(In reply to comment #3) > Let's wait for the outcome of Mozilla's security review [1]. It may find > Chrome's policy [2] acceptable (possibly with minimal changes that Chrome > could adapt to), and that could be added to the specification. > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c16 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5 Would someone from Mozilla speak to the completion of the security review [3] and how it affects this issue. Specifically, is Mozilla content with adding the additional checks Chrome uses outside of fullscreen to the specification ([2] above)? [3] https://bugzilla.mozilla.org/show_bug.cgi?id=822654
Olli Pettay, I see your work underway in Mozilla to implement pointer lock in windowed (non fullscreen) mode useing similar additional constraints as Chrome [1]. I would like to fold these constraints into the specification, but I'd like confirmation on the specifics. Does coment 5 [2] on that issue describe what you are implementing? It seems to be covered in comment 20 [3] except the ability to re-lock without user gesture after the application/page has voluntarily unlocked, but I see in the code [4] bool mAllowRelocking which seems to implement this. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=737100 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c20 [4] https://bug737100.bugzilla.mozilla.org/attachment.cgi?id=727599
Firefox builds now support a policy similar to Chrome, as discussed in [1]. I have updated the pointer lock specification [2] to clarify required behavior and recommend the optional behaviors chrome and firefox have adopted. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5 [2] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html