Re: Mouse Lock

On Fri, Aug 12, 2011 at 2:27 PM, Vincent Scheib <scheib@google.com> wrote:
> 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.

I'm asking whether we can reuse the existing notion of the "currently
focused element" and send mouse events to that element while the mouse
is locked.

>> 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?

If your implementation had to warp the mouse cursor on Windows to get
accurate delta information, the mouse position in the existing mouse
events would no longer be very meaningful and a new event type seemed
more logical. But assuming Klaas is right, we no longer need to worry
about this. It seems we can unconditionally add delta information to
existing mouse events. So I withdraw that comment.

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

OK.

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

And if Klaas is right, we don't even lose that.

Right now I'm thinking about full-screen apps. It seems to me that if
we add delta information to all mouse events, then full-screen apps
don't need anything else from your MouseLock API. Correct?

If so, I think it might be a good idea to make the delta information
API a separate proposal, and then adjust the use-cases for MouseLock
to exclude cases that only make sense for full-screen apps, and
exclude cases that can be satisfied with delta information + mouse
capturing with automatic release on button-up.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is
not in us. If we confess our sins, he is faithful and just and will
forgive us our sins and purify us from all unrighteousness. If we
claim we have not sinned, we make him out to be a liar and his word is
not in us." [1 John 1:8-10]

Received on Friday, 12 August 2011 05:14:58 UTC