W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Mouse Lock

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 20 Jun 2011 14:20:31 -0700
Message-ID: <BANLkTim=q5pN2oDgWUW_cVH2yWhckxhWr2pwEUWcm47YTTHTrQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Adam Barth <w3c@adambarth.com>, Vincent Scheib <scheib@google.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, "Gregg Tavares (wrk)" <gman@google.com>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
On Mon, Jun 20, 2011 at 12:18 PM, Jonas Sicking <jonas@sicking.cc> 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> wrote:
>>> On Mon, Jun 20, 2011 at 10:18 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>> So it sounds like we don't have a security model but we're hoping UA
>>>> implementors can dream one up by combining enough heuristics.
>>> A model which I suggested privately, and which I believe others have
>>> suggested publicly, is this:
>>> 1. While fullscreen is enabled, you can lock the mouse to the
>>> fullscreened element without a prompt or persistent message.  A
>>> temporary message may still be shown.  The lock is automatically
>>> released if the user exits fullscreen.
>> ^^^ This part sounds solid.
> Why do you need to lock the mouse when you're in full-screen mode? The
> mouse can't go outside the element anyway, right?
> Or is this to handle the multi-monitor scenario where a fullscreen'ed
> element might just cover one monitor.

Multi-monitor is one reason.  Another is that, even in single-monitor
fullscreen, some browsers pop up an overlay when the mouse hits the
top of the screen.  Mouselocking would allow browsers to keep doing
that in the normal case (it's useful) while making it not happen
during games.

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

Yes, which is why I suggest a persistent message be shown with
instructions on how to release the lock.  Thus the user is aware that
the website is being hostile and knows how to stop it long enough to
get away (clicking Back or closing the tab).

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC