Really excited about the pointer lock API. Makes the browser a viable gaming platform now.
Edit: There appears to be a bug in the pointer lock code - not sure what's going on, but my mouse is getting locked into the wrong monitor if I move the Firefox window between monitors.
For those not familiar with the problems: pointer grabs are notorious for being a pain to deal with. They have many strange corner cases and security problems. They also have weird interaction issues with things like modal windows, popups, screensavers and the like.
My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key. I guess there is a risk that the browser could hang in that state, though, which makes it even more important for Mozilla to focus on their browser's stability.
> My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key.
It is similar in other windowing systems. But, but...
You are in fullscreen mode with a pointer grab. An important window pops up over the full screen: "10 minutes of battery remaining". What is the state of the grab while this window is shown? Will the code holding the grab be notified of this window? How will the pointer grab behave while the pointer is over the other window? Will the other window able to gain focus with a click? Should windows over other fullscreen windows be allowed at all? In general, how will the pointer grab reflect on the OS windowing system's pointer grab?
Past windowing systems tells us that it is extremely difficult to get all this right if the code doing the grab and doing the window management are the same code, something that is not going to happen with web apps.
Since there's a good chance moving the mouse is moving some gun around in 3D space rather than any visible pointer, the answer should be the same as for normal 3D games: to use the pointer or other windows, you must press ESC.
As mentioned on a comment a little below, this was designed with security in mind. Requesting mouselock can only be done together with requesting fullscreen mode, which is only possible in response to user input (like pressing a button) and after that requires explicit authorization. Afterwards, pressing escape will always leave both fullscreen and mouselock.
This is the first browser to ship with this feature enabled, so overall the web isn't quite ready yet. But hopefully other browsers will follow suit soon.
This is very different. Preventing rightclick can be done silently, without the user intervening. Mouse lock, on the other hand, must be explicitly accepted by the user.
In fact, the current implementation ties this to fullscreen, combining the prompts into one. In other words, the only way mouse lock will happen is if the user clicks on a button for fullscreen and then allows the site to use fullscreen+mouse lock. So there is very little risk of annoyance here like there is with rightclick prevention (but is still exactly what a first person shooter needs).
Edit: There appears to be a bug in the pointer lock code - not sure what's going on, but my mouse is getting locked into the wrong monitor if I move the Firefox window between monitors.