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

Re: Mouse Lock

From: Vincent Scheib <scheib@google.com>
Date: Mon, 20 Jun 2011 09:07:33 -0700
Message-ID: <BANLkTimFwk253duzf3WJfwYH0oLRkKOE3ebyWpYEtYH7bwV1Aw@mail.gmail.com>
To: Adam Barth <w3c@adambarth.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
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 16:08:29 GMT

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