Re: [Pointer Lock] Few comments

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=711276
and https://bugs.webkit.org/show_bug.cgi?id=74660


On 12/16/2011 01:49 AM, Olli Pettay wrote:
> 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 Friday, 16 December 2011 00:02:52 UTC