We should do something "sensible" when pointer lock requests are made when there's no pointer. I suggest that we just fail pointer lock requests when there's no pointer (and dispatch a pointerlockerror event), and exit pointer lock if the pointer is unplugged. I was thinking this is particularly relevant to Metrofox, but it's still relevant to our other supported touch platforms B2G and Fennec. Pointer lock is currently preff'd on by default on all platforms BTW: http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#3985 I don't know how we can determine that we don't have a pointer. Maybe we'd have to use platform specific APIs to determine this.

Hopefully GetRawInputDeviceList() [1] could be used to query if we have a pointer and RegisterDeviceNotification [2] could be used to detect when it's removed on Windows. [1] http://msdn.microsoft.com/en-nz/library/windows/desktop/ms645598(v=vs.85).aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363431(v=vs.85).aspx

In the case of Metrofox and on desktop once bug 737100 is fixed and maybe in other products, we also need to handle the case where the pointer is locked and then we switch tabs; we need to release the pointer lock as we switch tabs, and regain it if we switch back.

Should we be publishing device info for something like this? Rather than just fail, content should be able to query what the device supports (has precise mouse, supports precise pointer lock) and also request events for when device characteristics change (mouse connected / disconnected).

Yeah, it makes sense to make data about the device's input support available to content somehow. (In reply to Chris Pearce (:cpearce) from comment #2) > we also need to handle the case where the pointer is locked > and then we switch tabs Chrome, which supports pointerlock outside of fullscreen, just exits pointer lock when a pointer locked tab is blurred. We could match that, it's simpler to implement too.

Let's spin up a thread on webapps if Mozilla thinks more than just an error event on requestpointerlock and an exit & change event upon loss of pointer is needed. E.g. - If you believe we should have the error event indicate, "Hey, no pointer available, actually". - If you believe a touch based device should support pointer lock, and we need to make spec changes to support that. etc...