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

I agree that pointer lock is quite useful outside of fullscreen, but
before attempting to codify that in the specification I would want buy
in from other browser vendors. I can appreciate an argument to remain
restricted to fullscreen.

Application developers can automatically escalate to requesting
fullscreen upon the first pointerlockerror given the current behavior
of FireFox.  It's more code, but not a burdensome amount.

If future abuse of the feature appears on the web, there may be other
criteria used by browsers to suppress the feature. The specification
states "The user agent determines if pointer lock state will be
entered" which allows for browsers to add additional constraints. I
could word that more explicitly if it would help. But my intent was
specifically to allow browsers to use additional discretion. E.g. see
the 'A full screen approach' in the specification's non-normative
security section. Also, note that Chrome allows users to enter global
suppression of the feature via the content settings preference, a
override accepted similarly by the specification.

Also, a small nit regarding "chrome requires the pointer lock request
to fail if not resulting from a user interaction target". Chrome
allows pointer lock without any user gesture if requested when in
fullscreen. Out of fullscreen a user gesture (click, key press) is
required. See http://www.chromium.org/developers/design-documents/mouse-lock

On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay <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. 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.

Received on Tuesday, 2 October 2012 22:09:08 UTC