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