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

On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:

> 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.
As I read through this thread, I was thinking exactly the same thing that Florian has said here. Looking forward to real feature completion ;)

Rick
  
>  
> On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib <scheib@google.com (mailto: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 (mailto:pyalot@gmail.com)> 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. 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.
>