Re: [Pointer Lock] Few comments

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



>
>     (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 21:42:28 UTC