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 <sch...@google.com > (mailto:sch...@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 <pya...@gmail.com > > (mailto:pya...@gmail.com)> wrote: > > > On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay <olli.pet...@helsinki.fi > > > (mailto:olli.pet...@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. >
