630979 - Implement mouse locking for WebGL-powered games

Status: RESOLVED DUPLICATE of bug 633602

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Dionysis Zindros]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.642.2 Safari/534.16
Build Identifier: 

I'm opening the bug to start a discussion in regards to the possibility of developing an API to allow webpages to "claim" the mouse so as to assist the development of WebGL/HTML5-based games.

In particular, what we need as developers is a means to let the user use the mouse inside our window without letting them leave. This is important, as, for example, in first person shooter or adventure games, it is often the case that the player can use the mouse to look around in a 3D environment. Rather than being able to detect the current position of the mouse on the screen, we need to be able to detect events such as "mouse moved left by such amount", or "mouse moved right by such amount".

It is crucial that there is no limit in how far the mouse can move. When the mouse is used as a cursor, it can move at most to the very left of the screen. In contrast, in games, the player is able to keep looking further to the left as much as they like, with no particular limitation.

Here's a quick API proposal:

Websites that desire to enable mouse locking can do so by explicitly requesting it through the browser API:

navigator.requestMouseLock( callback );

This would then ask the user if they'd like to explicitly allow mouse locking for the particular webpage, and offer to remember the option. When the user clicks Allow or Deny, the callback should then get called, with a parameter indicating the user choice:

function callback( choice ) {
   if ( choice ) {
      console.log( 'User allows mouse locking.' );
   }
   else {
      console.log( 'User disallows mouse locking.' );
   }
}

Upon allowing mouse locking, the cursor should not be allowed to leave the browser window, and it should promptly disappear (the website programmer can then choose to draw a cursor if they wish using for example WebGL). Furthermore, a new event will be made available allowing mouse movement checking:

window.onlockedmousemove = function () {
    // handle mouse move ...
    console.log( 'Mouse moved horizontally: ' + event.clientDX );
    console.log( 'Mouse moved vertically: ' + event.clientDY );
};

Hitting ESC should unlock the mouse and not allow the webpage to relock it before asking again. The way of asking could be similar to how the current location of the user is allowed to be accessed by the location API (an unobtrusive bar appearing at the top of the page).

Thank you for considering this feature.

Reproducible: Couldn't Reproduce

Comment 1

[Henri Sivonen (:hsivonen)]

It would make sense to start a discussion at the WHATWG or in the WebApps WG at the W3C.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Webevents WG might be even better place.

Anyway, this sounds a lot like set/releaseCapture.
Currently Gecko allows setCapture only during mousedown, IE apparently
at any time.
If we can figure out and fix the possible usability and security problems,
perhaps we could allow setCapture at any time.

Comment 3

[Markus Stange [:mstange]]

Duping to bug 633602 which has a bigger CC list and a link to the W3C bug.

Comment 4

[Elias Pierrakos]

Allowing us to take control over the mouse position will be a great benefit for HTML5 videogame development.

As it is, when actions are being determined my the mouse position, whenever a game starts, stuff happen with out the user moving the mouse at all.

Ideally, there should be an option to set the mouse inert (and on a specific place on the screen) until the user does something.

Comment 5

[nabizakaria2015]

well i think that the mozilla web developers community thought about it,,,and the reason of not activate such a function is because of security reasons,,,

if you stop a min and think about it you will see that i am total right  ,,,
 i was searching in this matter because of hacking reasons ,,,