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 10:18:54 -0700
Message-ID: <BANLkTiktVGZJxg4b7UWVj+g2rBdS7BQbLQ@mail.gmail.com>
To: Vincent Scheib <scheib@google.com>
Cc: 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
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.

Adam


On Mon, Jun 20, 2011 at 9:07 AM, Vincent Scheib <scheib@google.com> wrote:
> A range of security methods have been discussed. Please read the thread in
> detail if this summary is too succinct:
> The Security concern is that of the user agent hiding the mouse and not
> letting it be used normally due to malicious code on a web site. Thus, user
> agents must address this issue. No other security issue has been raised.
> A User agent has a large number of options to gauge user intent, and may use
> a combination of these techniques to avoid user frustration: prompt user
> before lock, is page full screen, require user gesture, avoid immediate
> relock, only lock on a forground page/tab in focus, per-domain permissions,
> installed application permissions, persistent instructional message to user
> on how to unlock, ESC key (or others) always unlocks.
>
> On Sat, Jun 18, 2011 at 11:38 PM, Adam Barth <w3c@adambarth.com> wrote:
>>
>> I'm sorry that I didn't follow the earlier thread.  What is the
>> security model for mouse lock?  (Please feel free to point me to a
>> message in the archive if this has already been discussed.)
>>
>> Thanks,
>> Adam
>>
>>
>> On Thu, Jun 16, 2011 at 3:21 PM, Vincent Scheib <scheib@google.com> wrote:
>> > [Building on the "Mouse Capture for Canvas"
>> >
>> > thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 ]
>> > I'm working on an implementation of mouse lock in Chrome, and would
>> > appreciate collaboration on refinement of the spec proposal. Hopefully
>> > webapps is willing to pick up this spec work? I'm up for helping write
>> > the
>> > draft.
>> > Some updates from Sirisian's Comment 12 on the w3 bug
>> > (http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c12):
>> > - We shouldn't need events for success/failure to obtain lock, those can
>> > be
>> > callbacks similar to geolocation API:
>> > (http://dev.w3.org/geo/api/spec-source.html#geolocation_interface).
>> >
>> > My short summary is then:
>> > - 2 new methods on an element to enter and exit mouse lock. Two
>> > callbacks on
>> > the entering call provide notification of success or failure.
>> > - Mousemove event gains .deltaX .deltaY members, always valid, not just
>> > during mouse lock.
>> > - Elements have an event to detect when mouseLock is lost.
>> > Example
>> > x = document.getElementById("x");
>> > x.addEventListener("mousemove", mouseMove);
>> > x.addEventListener("mouseLockLost", mouseLockLost);
>> > x.lockMouse(
>> >   function() { console.log("Locked."); },
>> >   function() { console.log("Lock rejected."); } );
>> > function mouseMove(e) { console.log(e.deltaX + ", " + e.deltaY); }
>> > function mouseLockLost(e) { console.log("Lost lock."); }
>> >
>
>
Received on Monday, 20 June 2011 17:19:54 GMT

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