JavaScript Pointer Lock (Mouse Lock) in Chrome Developer Preview (original) (raw)

Mouse Lock is the canonical term for when a game (or other application) removes the mouse cursor from view and interprets mouse motion for something else, e.g. looking around in a 3D world. To date this has not been possible for web applications without a plugin, which makes many game genres and other applications just terrible to use. (e.g. forcing users to drag the mouse button to pan the view, while a native application would use the mouse button for something else, e.g. interacting with the world.).

Good news: I've been working on a w3c specification to address this. The feature is available for developers to experiment with now in Chrome (details below). And, a FireFox implementation is on it's way too, thanks primarily to David Humphrey using it as a class project.

Today the first Chrome Canary build is available to try the feature out:

• Get a build.
  • Chrome Canary builds auto-update daily and install without interfering with your normal installation of Chrome, they're the way to go since they're so easy. Unless your on Linux, where you need to just get a recent Linux Build.
• Enable pointer lock.
  • Navigate to about:flags, find Enable Pointer Lock, and restart (there's a button below).
• Try a demo.
  • http://media.tojicode.com/q3bsp/ is a nice one from Brandon Jones and what you see in the screenshot above. It's a quake 3 BSP viewer.
  • Others are sure to show up soon, minutes after landing the keystone WebKit patch I received a few IMs and emails from excited developers.
• Go Fullscreen. (more on that later)
  • In Brandon's demo find the fullscreen button in the bottom right corner. (It has to be JavaScript initiated fullscreen, not chrome's "presentation mode".)
• Allow the site to disable your mouse cursor.
  • This setting is remembered for each site, and can be forgotten in Chrome's preferences / content settings.
• Read some doc https://developer.mozilla.org/en/API/Mouse_Lock_API.

There's a lot that will be changing with this. First, I have several issues still to deal with in the WebKit implementation, a security review will certainly find more, and oh yeah we're going to overhaul the spec to be as identical as possible to the Fullscreen spec.

Some have asked if pointer lock will be forever restricted to fullscreen mode. No, in fact by the time the JavaScript bindings ship without developer flags I'm hoping to have removed the restriction, and if not then soon after. The only real requirement is that the user not suffer from a poorly behaving website. At the moment that means if a site spams lock requests that we require a user-gesture (e.g. clicking on the web page content, or pressing a key). Fullscreen currently requires the same, so we hide in it's shadow, but I'll implement the check even in windowed mode.

Chrome 19 is the earliest JavaScript pointer lock could ship without a developer flag, but it's predicated on many things coming into place. However, Native Client apps have been able to use it since Chrome 16.

Happy locking.