Re: [Pointer Lock] Few comments

On 12/16/2011 01:04 AM, Darin Fisher wrote:
>
>
> On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     On 12/15/2011 11:27 PM, Vincent Scheib wrote:
>
>
>
>         On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay
>         <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>
>         <mailto:Olli.Pettay@helsinki.__fi
>         <mailto:Olli.Pettay@helsinki.fi>>> wrote:
>
>             Hi all,
>
>             few comments about the API
>
>             (1)
>             currently
>         http://dvcs.w3.org/hg/____webevents/raw-file/default/____mouse-lock.html
>         <http://dvcs.w3.org/hg/__webevents/raw-file/default/__mouse-lock.html>
>
>         <http://dvcs.w3.org/hg/__webevents/raw-file/default/__mouse-lock.html
>         <http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html>>
>             uses VoidCallback which isn't defined anywhere.
>
>             I guess there should be something like
>
>             void lock (in Element target,
>                        optional in LockSuccessCallback successCallback,
>                        optional in LockErrorCallback failureCallback);
>
>
>             [Callback,NoInterfaceObject]
>             interface LockSuccessCallback {
>               void pointerLockSuccess();
>             };
>
>             [Callback,NoInterfaceObject]
>             interface LockErrorCallback {
>               void pointerLockFailure();
>             };
>
>             Or if the new proposed callback syntax is used:
>             callback LockSuccessCallback = void pointerLockSuccess();
>             callback LockErrorCallback = void pointerLockFailure();
>
>
>         I used the concept of VoidCallback from other implemented specs. Are
>         there any issues with it other than that the spec should define
>         VoidCallback? e.g.
>         http://www.w3.org/TR/file-__system-api/#the-voidcallback-__interface
>         <http://www.w3.org/TR/file-system-api/#the-voidcallback-interface>
>         http://www.w3.org/TR/2009/WD-__DataCache-20091029/#__VoidCallback <http://www.w3.org/TR/2009/WD-DataCache-20091029/#VoidCallback>
>
>
>     well, in those specs VoidCallback is FunctionOnly= which it probably
>     shouldn't be.
>     But there is ongoing discussion about removing FunctionOnly= from
>     WebIDL
>
>
>
>
>
>             (2)
>         "If another element is locked a user agent must transfer the mouse
>             lock to the new target and call the pointerlocklost callback
>         for the
>             previous target."
>             There is no such thing as 'pointerlocklost callback'
>
>
>         Spec typo, it should read "pointerlocklost event".
>
>
>     dispatch pointerlocklost event...
>
>
>
>
>
>             (3)
>         "Mouse lock must succeed only if the window is in focus and the
>             user-agent is the active application of the operating system"
>             What window? window object as in web page? Or OS level window?
>             What if lock is called in some iframe?
>
>
>         The intent is the user-agent window and tab (if tabbed UA).
>         Other than
>         UA security considerations, I propose there be no difference between
>         lock calls from a top level document or an iframe. Suggestions
>         welcome
>         for a way to make this more clear than rewriting to be, "... succeed
>         only if the user-agent window (and tab, if a tabbed browser) is
>         in focus
>         ..."
>
>
>     I'm just worried about iframes being able to lock mouse.
>     But perhaps that should be allowed only if the iframe is in
>     the same domain as the top level document.
>
>
> The fullscreen API requires that the IFRAME tag have an
> "allowfullscreen" attribute:
> http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#security-and-privacy-considerations

The spec is quite vague, but yes, something similar could work.

I wonder if we're going to have more this kinds of features. If so, 
perhaps the attribute should be changed.
Something like
allow="fullscreen pointerlock"



>
> Perhaps a similar approach would work for pointer lock?
>
> -Darin
>
>
>
>
>
>             (4)
>         "If the target is removed from the DOM tree after mouse lock is
>             entered then mouse lock will be lost."
>             Should 'pointerlocklost' event be dispatched?
>
>
>         I'm not yet certain about the implementation practicalities, and
>         need to
>         research more, but is seems we have these options:
>         a- don't send the event
>
>     A bit strange
>
>
>
>         b- send to the element after it has been detached
>
>     I would assume this. At least it would be consistent.
>
>
>
>         c- send to the nearest ancestor of the element that remains in
>         the tree
>
>     Or perhaps send to the document. Should pointerlocklost always be
>     dispatched to the document? If really needed, the event could have
>     property .unlockedElement or some such.
>
>
>
>         d- send to the element before it is detached
>
>     this is not possible. Well, possible, but would bring in all the
>     problems there are with mutation events
>
>
>     -Olli
>
>
>

Received on Thursday, 15 December 2011 23:49:54 UTC