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

For those with threaded email clients, at Arthur's suggestion I've filed an
issue to track this topic.
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0040.html.


On Tue, Oct 2, 2012 at 4:50 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

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