W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Mouse Capture for Canvas

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 9 Feb 2011 22:06:28 -0500
Message-ID: <AANLkTik9VKr3YpGUgNk+SVH3U7XyROn+cdzr1pws2kOZ@mail.gmail.com>
To: Brandon Andrews <warcraftthreeft@sbcglobal.net>
Cc: Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
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.

(I also seriously doubt that any proposal will gain traction that causes
merely listening to an event to have side-effects.  That's not how DOM
events work.)

> 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.
- 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.

(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.)

> 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".

> Since grab has no opposite mousegrab doesn't work. (ungrab isn't an
English word and "let go" sounds wrong).

I don't think "ungrab" is unnatural, but I'm not too concerned with the
naming, aside from avoiding "capture".

--
Glenn Maynard
Received on Thursday, 10 February 2011 03:07:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT