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

Re: Mouse Capture for Canvas

From: Brandon Andrews <warcraftthreeft@sbcglobal.net>
Date: Wed, 9 Feb 2011 16:20:59 -0800 (PST)
Message-ID: <617410.6049.qm@web83809.mail.sp1.yahoo.com>
To: Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>
Cc: Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
> On Tue, Feb 8, 2011 at 11:09 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> That said, it would still help prevent non-malicious but misbehaving
>> scripts from accidentally taking over the browser, which can happen
>> anywhere, even on "trusted" sites.  However, that's just one possible way of
>> dealing with that problem, and browsers should be able to look for less
>> restrictive solutions (which is what I had in mind when I referred to how
>> operating systems deal with this).
>>
>>  "Trusted" sites aren't well defined, so for the time being, I'm fine with
>> them taking over the browser.
>>

> In this case, I'm mostly referring to sites where you've previously clicked
> "always allow this site to do this"--probably the usual case.  Legitimate
> sites aren't going to deliberately hijack the mouse cursor, but it might
> happen due to a bug, and I must always be able to escape without having to
> close the whole browser window.

When I wrote this up I was thinking of the easiest way to handle this without 
allowing a webpage to take a mouse over and over. To make things more flexible 
it could be simply on mouse down instead of click. Mouse down would allow a 
person to click and continue moving the mouse inside of the region without 
releasing.

Regarding forcing a user action before the mouse is captured/grabbed I think 
it's pivotal. If a page can simply call a method to capture the mouse everytime 
it's released it because exploitable. If a person accidently allows a page to 
capture their mouse they can just press the release key.

> For an API, I'd suggest simply adding "element.captureMouse()" and
> "element.releaseMouse()", with events when the mouse is actually captured
> and released.  Browsers can still choose to ignore captureMouse if not
> called in response to a click, and the spec can require that at the start if
> that's really wanted, but that behavior isn't baked permanently into the API
> and could be relaxed later on.

I hate to ask, since there could be use cases I'm missing, but what is a use 
case where a browser would need to grab the mouse immediately when the page 
starts? I'm not against the idea, but it might need a strategy to stop abuse. 
Here are some steps I see happening.

1) User directs their user-agent to a new page.
2) Javascript calls mousecapture
3) user-agent displays a yellow bar at the top informing the user that the page 
is requesting to capture the mouse
4) User selects allow
5) User presses escape
6) In the mouserelease callback there's a mousecapture call
7) User is confused why mouse didn't release and kills 6 people.

So we have to stop that (the mouse release and immediate capture). My proposal 
is if the user presses the release key twice in a row the yellow allow/deny bar 
is reset. But that assumes every human reacts the same way to mouse that is 
locked and keeps hitting the escape key. You'll need to find a solution because 
I can't think of one that works.

Also what are your guy's name ideas? I think I prefer mousecapture and 
mouserelease and just push aside the IE API.
Received on Thursday, 10 February 2011 00:21:32 GMT

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