Bug 202956 - [GTK] Implement support for Pointer Lock API
Summary: [GTK] Implement support for Pointer Lock API
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 99036 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-14 14:57 PDT by Carlos Alberto Lopez Perez
Modified: 2019-11-08 08:29 PST (History)
10 users (show)

See Also:


Attachments
Patch (46.66 KB, patch)
2019-11-05 05:45 PST, Carlos Garcia Campos
clopez: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Alberto Lopez Perez 2019-10-14 14:57:16 PDT
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/
Comment 1 Carlos Alberto Lopez Perez 2019-10-15 11:05:02 PDT
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.
Comment 2 Carlos Alberto Lopez Perez 2019-10-15 11:15:00 PDT
The feature in the WebKit Feature Status page:
https://webkit.org/status/#specification-pointer-lock
Comment 3 Carlos Garcia Campos 2019-11-05 05:45:53 PST
Created attachment 382817 [details]
Patch
Comment 4 Build Bot 2019-11-05 05:46:41 PST
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
Comment 5 Carlos Garcia Campos 2019-11-05 06:10:05 PST
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.
Comment 6 Carlos Alberto Lopez Perez 2019-11-05 06:55:55 PST
(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)
Comment 7 Carlos Garcia Campos 2019-11-05 07:12:24 PST
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.
Comment 8 Carlos Alberto Lopez Perez 2019-11-05 08:11:43 PST
Comment on attachment 382817 [details]
Patch

Tested both on X11 and Wayland. Works nicely :). The implementation also looks good to me. r=me
Comment 9 Carlos Alberto Lopez Perez 2019-11-05 08:31:24 PST
(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)
Comment 10 Carlos Garcia Campos 2019-11-06 00:06:39 PST
Committed r252126: <https://trac.webkit.org/changeset/252126>
Comment 11 Carlos Alberto Lopez Perez 2019-11-08 08:04:42 PST
*** Bug 99036 has been marked as a duplicate of this bug. ***