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
case.