

Idea: mouseFreeze, A solution for Browser FPS Games - vjeux
http://blog.vjeux.com/2011/javascript/idea-mousefreeze-a-solution-for-browser-fps-games.html

======
maushu
I believe you are talking about mouse lock
(<http://code.google.com/p/chromium/issues/detail?id=72754>), something
Sirisian and me (but mostly Sirisian) have been trying to push into the
browsers (right now chrome and hoping the other browsers catch on).

There are many problems regarding this idea, specially security for the user,
this is why it's hard to convince the people of the benefits for RTS and FPS
games.

~~~
azakai
Thanks for doing this. It would be great if this stuff takes off!

For completeness here is the Firefox bug tracking this:
<https://bugzilla.mozilla.org/show_bug.cgi?id=633602>

------
sp332
This should probably be a browser API, with a standardized "do you want this
page to steal your cursor" and "press escape to release cursor" interface.

------
jos3000
This could be a browser permission based feature, like location is at the
moment. The app asks the browser to prompt the user to give permission for
this domain to "Control your mouse pointer". The cursor should always be
released when you alt-tab away or press the ESC key (maybe the would need to
be a time limit within which the mouse couldn't be captured again).

~~~
icebraining
_> maybe the would need to be a time limit within which the mouse couldn't be
captured again_

Why not re-capture only when the user clicks on the game again? In fact, I
don't think the permission bar is needed at all, it would be implicitly given
by clicking.

Of course, ESC should always work. Which would actually work fine for most
games, since ESC presents a menu where the pointer isn't supposed to be frozen
anyway.

------
sorbus
So you go to a malicious website and it's able to move your mouse around or
lock it in place. That would not be a good situation to be in, especially for
the segment of the population that doesn't understand keyboard shortcuts
(which would, presumably, allow escape from this). Even if it's not used
maliciously, it seems very plausible that it would be used to make
advertisements harder to avoid (on websites like Hulu that run ads during a
video, preventing most users from being able to go elsewhere during them could
be a tempting idea).

I get why something with this effect is necessary if we are to have FPS games
running in the browser, I just don't think that it's a good idea to allow
websites to do so without explicit user permission. Admittedly, there are few
things I hate as much as programs moving my mouse around, so I'm a bit biased.

~~~
strager
The article's suggestion does not say the mouse would be moved or locked by
the web program. The program would be able to hide the cursor (which it can
already do) and receive 'virtual' mouse coordinates.

My main concern is number overflow for long-running applications, but I
seriously doubt this will be a problem for anyone.

I don't see any security problems with the proposed solution (though I don't
claim to be a security expert!).

~~~
sorbus
I may be hugely misreading the article, but when it says "The mouse will be
anchored to that position and the mousemove events are going to set a virtual
position" and "Everytime the user moves the mouse ... the cursor is moved to
the center of the screen" I find it difficult to interpret that in any way
that doesn't effectively mean that a website is able to move or lock the
cursor. I admit that I use cursor and mouse interchangeably, when they're
actually not the exact same thing, however.

~~~
strager
Okay, I missed "The mouse will be anchored to that position" part. I really
disagree with this part of the proposal. Thanks for pointing it out.

However, the comment about the cursor moving to the centre of the screen is an
_implementation detail_. At least on Windows, you need to centre the mouse
cursor for something like this because the OS won't (easily) give you actual
virtual coordinates.

------
thristian
It sounds like there's two main use-cases here:

\- Infinite dragging of a particular element; for example, scrolling in Google
Maps or the sort of 'click and drag' UI of a typical billiards or mini-golf
game.

\- Relative movement events in general, as used for 'mouse-look' in FPS games.

For the first use-case, it should be pretty easy to deal with. Add a property
to the 'mousedown' event called 'relativeMode' (or whatever), initially set to
false. If the event-handler sets 'relativeMode' to true, then instead of
sending the usual string of 'mousemove' events to elements the cursor moves
over, the browser should capture ("freeze") the mouse, hide the cursor, and
deliver 'mousedelta' events to the original element (whose x and y properties
contain the movement delta from the location of the original mousedown event).
When the user lets go of the mouse button, the browser releases the capture
and shows the cursor. There's no security issue, because the user is in
control of the capture at all times, and can just release the mouse button
whenever they want.

The second use-case is a bit more troublesome, but as the Chrome bug linked
elsewhere in this thread mentions, "web-pages in full-screen mode effectively
own the cursor anyway". Perhaps a similar 'relativeMode' property could be
added to the 'fullscreen' event.

------
antimatter15
I think a much simpler idea would to have a onmousedelta event which fires
whenever the mouse moves and that tab has focus (including outside window
boundary) and includes a .deltaX and .deltaY event property.

That way, the user has full control over their mouse and you can also develop
fps games.

~~~
nitrogen
It's unlikely that the operating system's standard mouse events will continue
to report mouse movement when the cursor runs into the edge of the screen.
Plus it would be very distracting to have a mouse cursor running around
outside the active window.

------
whackberry
Anyone seriously considering the web browser as a platform for future 3d
gaming is, of course, in a state of sin.

(stolen from Jon Von Neumann's famous random number quote)

