Re: Mouse Lock

On Mon, Jun 20, 2011 at 1:19 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 06/20/2011 10:18 PM, Jonas Sicking wrote:
>> On Mon, Jun 20, 2011 at 11:17 AM, Adam Barth<w3c@adambarth.com>  wrote:
>>> On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr.<jackalmage@gmail.com>
>>>> 2. During a user-initiated click, you can lock the mouse to the target
>>>> or an ancestor without a permissions prompt, but with a persistent
>>>> message, either as an overlay or in the browser's chrome.
>>>
>>> ^^^ That also sounds reasonable too.  There's some subtly to make sure
>>> the message is actually visible to the user, especially in desktop
>>> situations where one window can overly another.  It's probably also
>>> useful to instruct the user how to release the lock.
>>
>> Hmm.. I'm less comfortable with this I think. It's always very easy to
>> get the user to click somewhere on a page, so this effectively means
>> that it's very easy for any page to lock the mouse.
>
> Yeah. Mouse could be locked on mousedown, but it should be automatically
> released on mouseup.
> That is the way set/releaseCapture works in Firefox.
>
> Other cases should need explicit permission from user.

The use-case is non-fullscreen games and similar, where you'd prefer
to lock the mouse as soon as the user clicks into the game.  Minecraft
is the first example that pops into my head that works like this -
it's windowed, and mouselocks you as soon as you click at it.

Requiring a permissions prompt in this case would be suboptimal, as it
would mean the user needs to click at least two things to actually
play the game.  (The game itself, and then the permissions prompt.)

Releasing on mouseup isn't useful for mouselock.  The sorts of things
that you can do on a drag like that are captured by the mousecapture
concept, which is distinct.

~TJ

Received on Monday, 20 June 2011 21:26:31 UTC