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.
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.
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).
>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.
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.
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!).
- 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.
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.
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.
What happens when the user moves the cursor outside the window, and then clicks? Or moves the cursor into a hot corner of the screen, activating something like a screen saver?
Deltas are necessary but are only part of the solution.
[+] [-] maushu|14 years ago|reply
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|14 years ago|reply
For completeness here is the Firefox bug tracking this: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
[+] [-] vjeux|14 years ago|reply
[+] [-] sp332|14 years ago|reply
[+] [-] jos3000|14 years ago|reply
[+] [-] icebraining|14 years ago|reply
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|14 years ago|reply
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|14 years ago|reply
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!).
[+] [-] thristian|14 years ago|reply
- 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|14 years ago|reply
That way, the user has full control over their mouse and you can also develop fps games.
[+] [-] nitrogen|14 years ago|reply
[+] [-] krevis|14 years ago|reply
Deltas are necessary but are only part of the solution.
[+] [-] AltIvan|14 years ago|reply
[deleted]
[+] [-] whackberry|14 years ago|reply
(stolen from Jon Von Neumann's famous random number quote)