Re: Mouse Lock

Continuing Alexey Proskuryakov's thread from the WebKit bug:
https://bugs.webkit.org/show_bug.cgi?id=68468#c17

>> It is reasonable for the application to accept text input to an element that is different than where mouse events are being dispatched.
>
>I don't really see what this has to do with keyboard events. They'll still got to a focused element whether mouse is locked or not, correct? This doesn't mean that mouse events need a custom target.

Mouse events are dispatched to a target. Under mouse lock they are as
well, which provides for implementations to build handling code in
that elements local component. I see no harm in dispatching mouse
events to a target.

>>> - Why document.lockMouse() instead of navigator.lockMouse()?
>> Is there a reason navigator would be more appropriate?

.lockMouse is not placed on window to avoid polluting the global
namespace. Document and navigator appear functionally equivalent.
However, historical use of navigator has not included this type of
functionality. I've no particular objection to placing the api there
if there is a reason to do so vs document. Your suggestion:

>Sure, you wouldn't need to worry about which subframe's document to call it on.

holds true for navigator as well, so it is not a reason to place the API there.

Finding an element's document is convenient via element.ownerDocument,
and doesn't seem to pose a problem.

Further, I would suggest that for convenience .lockMouse should
succeed even when the document and element do not come from the same
document. Security/nuisance concerns remain the same via content
settings per origin, not script level access.

I'll update the spec appropriately.

>> Callbacks for the asynchronous success or failure of a call to lockMouse serve the need without adding unnecessary new events, and is a pattern already established in recent specs such as geolocation. Are there any issues with this? You haven't identified any inconsistencies.
>
>I'm not sure how to answer this. I said that some events are delivered as events, and others as callbacks. How is that "you haven't identified any inconsistencies"?

Events are used for events. Callbacks are used for call backs. This is
similar to using a float and an int for the appropriate variable
types. An example of an inconsistency would be to have some call backs
routed through event handlers, and others via function pointers.

I'll make no change to the spec and close this topic unless you have
an alternative suggestion and justification.

>> You do not believe a click event should be able to be dispatched from JS to another element?
>
>What I "believe" is that synthetic events do not trigger a default action per HTML5. It's implicit in the spec, but you can see bug 64580 comments 79 and 80 for a succinct explanation from Hixie.
>
>You can certainly dispatch a click event on a button, and you can handle it in a custom event handler, but the button itself won't do anything in response.

The spec states in a normative section that "Synthetic mouse events
created by application script act the same regardless of lock state."
to point out that this remains possible. This is because we would like
to best support the informative use case's section on "Synthetic
cursor interaction with HTML DOM UI". You have observed that synthetic
clicks are not equivalent to non-synthetic clicks.

I will update the use case section describing this limitation. The
intent of the use case stands, which is that when under mouse lock an
application may still make use of the web platform for user interface
with an app controlled cursor.

>> You can not today drag a job control in a single direction with unlimited input.
>
>OK, I better understand this use case now. It's really questionable if this kind of functionality should be available to web applications at all.

There is currently no normative portion of the spec that exists solely
to serve this use case, so we are happy to see that application
developers will have it as an option as they choose.

>> On the topic of acceleration and calibration, there seems to only be speculation that this is harmful.
>
>I remember seeing an FPS shooter game that didn't compensate for mouse acceleration, it was basically unplayable. It seems obvious that acceleration that's good for linear movement won't be as good when applied to controlling 3D view.

You have provided more speculation when direct reports from game
developers having shipped games contradict it. I encourage you to
experiment with a prototype implementation to understand this
principal.

>> Users who desire no acceleration can configure it the same way they do with games today (system configuration, drivers, or in game)
>
>Are you really suggesting that users will manually tweak global system settings before playing a 3D game in a browser, and change them back afterwards?

No, because they will not need to, see previous point.

Received on Thursday, 20 October 2011 22:45:11 UTC