- From: Vincent Scheib <scheib@google.com>
- Date: Mon, 20 Jun 2011 09:07:33 -0700
- 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
- Message-ID: <BANLkTimFwk253duzf3WJfwYH0oLRkKOE3ebyWpYEtYH7bwV1Aw@mail.gmail.com>
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 UTC