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

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 03 Oct 2012 01:13:19 +0300
Message-ID: <506B66FF.1090505@helsinki.fi>
To: Florian Bösch <pyalot@gmail.com>
CC: Chris Pearce <cpearce@mozilla.com>, Vincent Scheib <scheib@google.com>, Arthur Barstow <art.barstow@nokia.com>, "public-webapps@w3c.org" <public-webapps@w3c.org>
On 10/03/2012 12:59 AM, Florian Bösch wrote:
> On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>> wrote:
>     On 10/02/2012 11:55 PM, Florian Bösch wrote:
>         I'd like to point out that vendors are using additional failure criteria to determine if pointerlock succeeds that are not outlined in the
>         specification. Firefox uses the fullscreen change event to determine failure and chrome requires the pointer lock request to fail if not resulting
>         from a user interaction target. I think that Firefoxes interpretation is less useful than Chromes,
>     But safer
> Also not in conformance to the specification (hence a bug). Additionally, it will make it really difficult to follow the specification since
> non-fullscreen mouse capture is specifically intended by the specification by not adding that failure mode *to* the specification (there's a fairly
> long discussion on this on the chrome ticket for pointerlock resulting in what Chrome does now).
>       and that Chromes interpretation should be amended
>         to the spec since it seems like a fairly good idea.
>     I'm not yet convinced that it is safe enough.
>     Also, it is not properly defined anywhere.
> So either Chrome is also implementing in conformance to the specification, or the specification is changed.
Chrome is not following the spec, because per spec one should be able to call requestPointerLock() whenever
the window/browser is focused and element is in document (the spec doesn't btw say which DOM tree)
and there is no sandboxed pointer lock flag.

> Ipso facto, the specification is not
> complete

> since I don't think Chrome will drop this failure mode, and it seems like Firefox is intending to follow Chromes lead because otherwise it
> wouldn't be possible to implement non-fullscreen pointerlock.
Chrome has implemented the feature using one permission model. It is possible the Firefox will use the same, but the model
is such that it certainly needs a proper security review.

Received on Tuesday, 2 October 2012 22:13:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC