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

Re: Mouse Lock

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 20 Jun 2011 11:17:20 -0700
Message-ID: <BANLkTikds73C00wGNtx+YUcQrRzMWxHFmg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: 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 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.

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

> 3. Otherwise, any attempt to lock the mouse triggers a permissions
> prompt, and while the lock is active a persistent message is shown.

^^^ This part sounds scary.  What's the use case for locking the mouse
without the user interacting with the page?

> These wouldn't be normative, of course, because different platforms
> may have different permissions models, but they seem like a good
> outline for balancing user safety with author convenience/lack of user
> annoyance.

Sure, it shouldn't be normative, but it's important to think though
the security model for features before adding them to the platform.

Received on Monday, 20 June 2011 18:18:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC