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

Re: Mouse Lock

From: Gregg Tavares (wrk) <gman@google.com>
Date: Mon, 27 Jun 2011 17:59:36 -0700
Message-ID: <CAKZ+BNoRc8kN=O25cZa_etBTk71fECsuESqHUMU4mSL4T8R9GA@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Simon Pieters <simonp@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Barth <w3c@adambarth.com>, Vincent Scheib <scheib@google.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
On Fri, Jun 24, 2011 at 10:58 AM, Aryeh Gregor <Simetrical+w3c@gmail.com>wrote:

> On Wed, Jun 22, 2011 at 5:20 AM, Simon Pieters <simonp@opera.com> wrote:
> > On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor <
> Simetrical+w3c@gmail.com>
> > wrote:
> >> There's a middle ground here: you can lock the mouse to the window,
> >> but not completely.  That is, if the user moves the mouse to the edge,
> >> it remains inside, but if they move it fast enough it escapes.  This
> >> is enough to stop the window from accidentally losing focus when
> >> you're trying to click on something near the edge of the screen, but
> >> it lets you easily get outside the window if you actually want to.
> >> IIRC, Wine does this in windowed mode.  Of course, it might not be
> >> suitable for games that want to hide the cursor, like FPSes, but it
> >> might be a possible fallback if the browser doesn't trust the site
> >> enough for whatever reason to let it fully lock the mouse.
> >
> > This seems weird. When would you use this middle ground? Would users
> > understand it? Also, as you say, totally inappropriate for FPS games.
> Well, the time when I noticed it in Wine is when I was running some
> kind of isometric RPG or strategy game or something, and had to run in
> windowed mode because it was buggy in fullscreen.  In these games you
> have a map, and you scroll around on the map by moving the mouse to
> the edge of the screen.  You do have a visible mouse cursor, but you
> don't want it to leave the window because then you have to position it
> pixel-perfect to get the window to scroll, instead of just slamming it
> against the side.
> Of course, you could just trap the mouse for real in this case as
> well.  In practice that might be fine.  Also, it occurs to me that the
> author could always make the cursor transparent if they wanted to
> confuse the user, and the user might not think to move it quicker to
> get it out even if they could see it (although it's an intuitive thing
> to try).  So it might not be a security advantage at all relative to
> actually locking the cursor.
> But this does highlight the fact that we probably want to support
> mouse-locking that doesn't hide the cursor also, for this kind of
> mouse-based scrolling.  In that case, though, the coordinates and
> mouse events should behave just like regular.  If the user presses the
> cursor up against the side of the screen and it visually stops moving,
> no mousemove events should be fired even if the user does keep moving
> the actual mouse.  The application would then want to check the
> cursor's location instead of listening for events.

As far as I know if a game wants to limit movement of the mouse inside a
window they just mouselock and display their own mouse pointer. The original
is hidden and their pointer logic uses the deltas to move their software
mouse pointer.

That's a simpler solution than adding stuff to the API for this specific
Received on Tuesday, 28 June 2011 01:00:04 UTC

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