On Wed, Feb 9, 2011 at 11:37 PM, Brandon Andrews < warcraftthreeft@sbcglobal.net> wrote: > So what you'd prefer would be to allow the mouse to call element.lockMouse(), element.unlockMouse() whenever it wanted. Then assume the user-agent will perform restrictions? > These restrictions would be asking the user to allow the action and preventing abuse? > Sounds good. This gets rid of the events completely. The events should still exist, so you can tell if your request was accepted, and you can tell if the browser has locked or unlocked the mouse for other reasons, such as pressing a hotkey to release the mouse. There should probably also be a "lockrefused" event, to notify that a lock request was rejected. > Assuming that a person can call the lock function whenever in any mouse or keyboard event then there is no initial interaction required. Sounds like what you want, and it would be very flexible. This would still require initial interaction; for example, in the "lobby timer" case, you'd still have to do something--click the screen or press a key--to initiate it. Methods for relaxing that can be explored later. For example (as mentioned just previously) a browser might allow locking the mouse without any interaction if the page is fullscreened, or if the page is acting as a standalone application (eg. an "application shortcut" in Chrome or a Chromium packaged app). (If this gains any traction, of course--agreeing about something here doesn't automatically make things get implemented. :) -- Glenn Maynard
Received on Thursday, 10 February 2011 06:03:58 UTC