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

Speaking from the point of view of a web developer having to use this
feature. It is quite painful having to perform an end-run about failure
modes that are unspecified, undocumented and a moving target. In my
understanding, this is precisely the intent of a specification, to avoid
such incompatibilities and headaches for developers.

1) If it is intended that additional failure modes are to be randomly
introduced by vendors, then this should be made explicit in the
specification.
2) If such wording is added to the specification, I don't see any residual
value in the specification since any developer will have to perform the
trial&error endrun repeatedly patching things up as the failure modes move,
we can just skip the specification altogether.

On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib <scheib@google.com> wrote:

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