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.pet...@helsinki.fi
<mailto:olli.pet...@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.pet...@helsinki.fi <mailto:olli.pet...@helsinki.fi>
<mailto:Olli.Pettay@helsinki.__fi
<mailto:olli.pet...@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
