W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [Pointer Lock] Few comments

From: Vincent Scheib <scheib@google.com>
Date: Thu, 15 Dec 2011 13:27:22 -0800
Message-ID: <CAK-EfXksUxNKDw-w2zgTRcjTabTjEJ5MOeLf+=em4twVr4rBvg@mail.gmail.com>
To: olli@pettay.fi
Cc: Webapps WG <public-webapps@w3.org>
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay <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



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

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

(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
b- send to the element after it has been detached
c- send to the nearest ancestor of the element that remains in the tree
d- send to the element before it is detached
Received on Thursday, 15 December 2011 21:28:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT