Re: Mouse Lock

On Thu, Oct 20, 2011 at 3:44 PM, Vincent Scheib <scheib@google.com> wrote:

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

Note this bug:
https://bugs.webkit.org/show_bug.cgi?id=27880

WebKit does not yet support the HTMLElement click() method.




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