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/
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.
The feature in the WebKit Feature Status page: https://webkit.org/status/#specification-pointer-lock
Created attachment 382817 [details] Patch
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
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.
(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)
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 on attachment 382817 [details] Patch Tested both on X11 and Wayland. Works nicely :). The implementation also looks good to me. r=me
(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)
Committed r252126: <https://trac.webkit.org/changeset/252126>
*** Bug 99036 has been marked as a duplicate of this bug. ***