Re: Mouse Lock

Re Rob:
> Is there a need to provide mouse-locking on a per-element basis? It seems
to
> me it would be enough for mouse-locking to be per-DOM-window (or
> per-DOM-document) and deliver events to the focused element. This
simplifies
> the model a little bit by not having to define new state for the
> "mouse-locked element". Or is there a need for mouse-lock motion events to
> go to one element while keyboard input goes elsewhere?

I may need to clarify the specification to state that there is only a single
state of mouse lock global to the user agent. You may be suggesting that the
MouseLockable interface be added to only the window and not to all elements?
An argument was made that multiple elements may attempt a mouseLock,
especially in pages composing / aggregating content. If so, it would be
undesirable for an unlockMouse() call on one element to disrupt a lock held
by another element. I will update the spec to explain that decision. If you
were suggesting something else, I didn't follow you.

> As was suggested earlier in this thread, I think given we're not
displaying
> the normal mouse cursor and in fact warping the system mouse cursor to the
> center of the screen in some implementations, we shouldn't deliver normal
> mouse-move events. Instead, while mouselock is active, we should deliver a
> new kind of mouse motion event, which carries the delta properties. If you
> do that, then hopefully you don't need a failure or success callback. Your
> app should just be able to handle both kinds of mouse motion events.

The argument is that mouse handling code can be simplified by always
handling the same MouseEvent structures. The six modifier key and button
state  members and event target are still desired. When not under lock the
movement members are still useful - and are tedious recreate by adding last
position and edge case handling in mouseleave/enter.

The success or failure events are desired to be once per call to lock, for
appropriate application response. Triggering that response logic on every
mouse event, or detecting the edge of that signal seems more complicated.
The callbacks are also low cost, they can be inline anonymous functions or
references.. they don't take special event handler registration.

What am I missing in the value of having new event types?

>
> I'm not really sure how touch events fit into this. Unlike mouse events,
> touch events always correspond to a position on the screen, so the delta
> information isn't as useful. (Or do some platforms detect touches outside
> the screen?) Maybe the only thing you need to do for touch events is to
> capture them to the focused element.

The motivation for touch events is to make capturing to a specific element
easy, including any other window content out of an apps control (e.g.
if embedded via iframe) and or any user agent UI that disables its
interaction when in mouse lock to offer a better app experience.


> In many of your use cases, it's OK to automatically release the mouse-lock
> on mouse-up. If you automatically release on mouse-up, the security issues
> are far less serious. So I think it would be a good idea to allow
> applications to accept that behavior via the API.

You mean you'd prefer the API have an option specified in lockMouse(...) to
cause the mouse to be automatically unlocked when a mouse button is let up
if the lock occurred during an event for that button being pressed? Under
current API draft an application specifies that with a call to unlockMouse
at a button up event.

I'm hesitant to add it, since it seems relevant only for the lower priority
use cases. The killer use case here is first person controls or full mouse
control applications. The mouse capture API satisfies most of the use cases
you're referring to, with the only limitation being loss of movement data
when the cursor hits a screen edge. I don't think we should complicate this
API for those nitch use cases when the functionality is available to them in
this API without great effort.

> A lot of this would be much simpler if we could somehow get mouse delta
> information from all platforms (Windows!) without having to warp the
cursor
> :-(. Has research definitively ruled out achieving that by any combination
> of hacks?
>
> Rob

Deltas alone don't satisfy the key use cases. We must prevent errant clicks.

Re: Klaas Heidstra

> You actually can get mouse delta info in windows using raw WM_INPUT data
> see: http://msdn.microsoft.com/en-us/library/ee418864(VS.85).aspx. This is
> also the only way to take advantage of > 400dpi mice, which is useful for
> FPS games.
>
>
Thanks for implementation tip!



> As for mouse locking isn't that a completely distinct feature from getting
> mouse delta information? For example in full-screen mode (and only using one
> screen) there is no need for mouse lock when you always can get mouse delta
> (because the mouse can't leave the screen).
>

It is the combination of mouse capture, hidden cursor, deltas being provided
with no limits of screen borders. It is valuable to have it work in non-full
screen mode.


>
> The only problem that remains is when in multi-screen and/or
> non-full-screen-mode, the mouse cursor can go outside the "game viewport".
> This is something that could be solved by mouse lock. But wouldn't it be
> better (as previously suggested in this thread) to implement "walling of the
> mouse cursor" by limiting the mouse cursor to the bounds of a targeted
> element. This is both useful for FPS-type games and RTS's. FPS's can hide
> the mouse cursor using CSS and don't have to worry about mouse events being
> fired outside the element or window. RTS-games just could use the available
> mouse cursor without needing to hide it (they wouldn't even need the mouse
> delta that way).
>
> It appears to me that mouse lock is just a workaround/hack that originated
> from the assumption that you can't get mouse delta info in Windows. Isn't it
> always better to first make an ideal design before looking at platform
> limitations that possibly could undermine that design?
>
> So to summarize all the above, design to separate features: 1. an event for
> getting mouse delta 2. an API for walling the mouse to an element.
>
> Klaas Heidstra


I'd like a solution for non full-screen apps, and I'd like it to work on
more than Windows.

I'll have to think about cursor confinement as a fine grained API. It may
raise security issues as it allows JS code to warp the cursor (fix: you can
only constrain to the element the event is triggered on by user action?).