Bug 202956 – [GTK] Implement support for Pointer Lock API

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Alberto Lopez Perez]

The Pointer Lock API (formerly called Mouse Lock API) provides input methods based on the movement of the mouse over time (i.e., deltas), not just the absolute position of the mouse cursor in the viewport. It gives you access to raw mouse movement, locks the target of mouse events to a single element, eliminates limits on how far mouse movement can go in a single direction, and removes the cursor from view. It is ideal for first person 3D games, for example.

https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
https://www.w3.org/TR/pointerlock/

There is currently a CMake guard ENABLE_POINTER_LOCK for this feature, its disabled by default on CMake ports.
On Mac port seems enabled by default.

WPT tests at: http://w3c-test.org/pointerlock/

[Carlos Alberto Lopez Perez]

More tests:

https://mdn.github.io/dom-examples/pointer-lock/
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/movementX


I have tested to just flip the switch in CMake but is not enough, some platform specific code needs to be implemented.

[Carlos Alberto Lopez Perez]

The feature in the WebKit Feature Status page:
https://webkit.org/status/#specification-pointer-lock

[Carlos Garcia Campos]

Created attachment 382817 [details]
Patch

[EWS Watchlist]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Carlos Garcia Campos]

We need to add API for this too. I think we could use the permission request API, but defaulting to allow, because other browsers don't ask permission to the user, they just show a message to indicate how to get your pointer back.

[Carlos Alberto Lopez Perez]

(In reply to Carlos Garcia Campos from comment #5)
> We need to add API for this too. I think we could use the permission request
> API, but defaulting to allow, because other browsers don't ask permission to
> the user, they just show a message to indicate how to get your pointer back.

Another idea to expose a runtime setting in WebKitSettings that allows to disable the feature (pretty much like we do with the enable-fullscreen API). That way if the feature its disabled it doesn't get exposed in the JS API ('pointerLockElement' in document)

[Carlos Garcia Campos]

The application still needs to be notified when the pointer is locked to show a message. The permission request API would cover both cases (being notified and being able to disable the feature). The only problem is if we want to also notify the application when the pointer has been released, I'm not sure that's useful, but in that case we would need signals in WebKitWebView instead.

[Carlos Alberto Lopez Perez]

Comment on attachment 382817 [details]
Patch

Tested both on X11 and Wayland. Works nicely :). The implementation also looks good to me. r=me

[Carlos Alberto Lopez Perez]

(In reply to Carlos Alberto Lopez Perez from comment #8)
> Comment on attachment 382817 [details]
> Patch
> 
> Tested both on X11 and Wayland. Works nicely :). The implementation also
> looks good to me. r=me

The pass-rate for WPT tests is also quite good:

web-platform-test
~~~~~~~~~~~~~~~~~
Ran 56 checks (49 subtests, 7 tests)
Expected results: 49
Unexpected results: 7
  test: 3 (2 error, 1 timeout)
  subtest: 4 (3 fail, 1 notrun)

[Carlos Garcia Campos]

Committed r252126: <https://trac.webkit.org/changeset/252126>

[Carlos Alberto Lopez Perez]

*** Bug 99036 has been marked as a duplicate of this bug. ***