Re: Mouse Lock

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.

Received on Friday, 24 June 2011 17:59:36 UTC