Re: Mouse Capture for Canvas

> On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews <warcraftthreeft@sbcglobal.net> 
>wrote: >>> If I load a first-person game in a tab, I shouldn't need to click the 
>>>> window >>> to allow the page to capture the mouse.  That'll force every game 
>to >>> start >>> with a superfluous box saying "click here to start". >> >> So 
>right when you go to that tab even just to glance at it your mouse will >> be 
>grabbed.  > That depends on how it's implemented.  (I'd rather not go into 
>specifically > how I think browsers might do this--those particular details 
>aren't the > point, at least at this stage.)

> Of course, browsers can still choose to only allow initiating a grab on > 
>click, and it can even be codified in the spec if that's what people really > 
>want.  Again, the point is that it's not necessary to do that in a way > that's 
>impossible to change later on.  If grabbing the mouse happens by the > act of 
>receiving a particular event, then it's impossible to ever relax the > 
>restriction without making a whole new API. 
>
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.
 >> I want to point out that most FPS games have a menu at the front.  > Try not 
to make too many assumptions about UIs.  A couple more examples:  > - Depending 
on clicking on the main menu to grab the mouse is brittle.  It > means you need 
to determine *at the time of the click* whether to grab the > mouse.  For 
example, if you have "start game" and "options" menu items, the > menu item 
itself needs to know to grab the mouse when "start game" is > clicked, but not 
when "options" is clicked.  That's an ugly, limiting > design. > - It breaks 
down in a typical "lobby" UI.  For example, you have a window > where people can 
join a game about to start, set options, chat, etc., with a > timer counting 
down for the game to start.  When the timer reaches 0, the > lobby UI goes away 
and the game starts--and everyone's mouse should be > grabbed without needing to 
click the window again.

I can agree with that use-case. Sounds like something to allow.

> - VMware grabs keyboard and mouse input to redirect it to the VM.  You can > do 
>this by clicking the window, but you can also do it with a keyboard > shortcut 
>(^G), so you can fully grab input with the keyboard alone.  This > should be 
>allowed from the start: mouse grabbing should be allowed from any > input event 
>(other than mousemove), including keyboard events. 
>
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.
 > (Please don't nitpick the individual examples; the point is that there are > 
lots of cases where it makes sense to grab the mouse without it being in > 
response to a click.) 

I won't, but these examples will help to refine and point out problems. I think 
we're finding a pretty solid solution.
 >> But yeah the main problem with just grabbing the mouse is that people just 
>> switching through tabs probably don't want their mouse grabbed. That and >> 
what happens when a tab isn't in view when capture is called?  > It fails, as if 
the user was prompted for permission and clicked "no". 

That works.