Re: [Pointer Lock] Few comments

On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay <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 <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

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