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.r...@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 trialerror 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 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 wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay 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.
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 27/09/12 08:37, Vincent Scheib wrote: On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. I agree. No one involved on our side of things is aware of any remaining issues with the pointer lock spec. Chris Pearce (Mozilla's pointer lock implementation maintainer)
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'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, and that Chromes interpretation should be amended to the spec since it seems like a fairly good idea. On Tue, Oct 2, 2012 at 10:37 PM, Chris Pearce cpea...@mozilla.com wrote: On 27/09/12 08:37, Vincent Scheib wrote: On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/**en-US/demos/detail/bananabreadhttps://developer.mozilla.org/en-US/demos/detail/bananabread **, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/**pointerlock/log/default/index.**htmlhttp://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. I agree. No one involved on our side of things is aware of any remaining issues with the pointer lock spec. Chris Pearce (Mozilla's pointer lock implementation maintainer)
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 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 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. On Tue, Oct 2, 2012 at 10:37 PM, Chris Pearce cpea...@mozilla.com mailto:cpea...@mozilla.com wrote: On 27/09/12 08:37, Vincent Scheib wrote: On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/__en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread__, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/__pointerlock/log/default/index.__html http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. I agree. No one involved on our side of things is aware of any remaining issues with the pointer lock spec. Chris Pearce (Mozilla's pointer lock implementation maintainer)
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 Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: 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.
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 pya...@gmail.com wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay 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.
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 10/03/2012 12:59 AM, Florian Bösch 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. Chrome is not following the spec, because per spec one should be able to call requestPointerLock() whenever the window/browser is focused and element is in document (the spec doesn't btw say which DOM tree) and there is no sandboxed pointer lock flag. Ipso facto, the specification is not complete Yup. 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. Chrome has implemented the feature using one permission model. It is possible the Firefox will use the same, but the model is such that it certainly needs a proper security review. -Olli
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 trialerror 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 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 wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay 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.
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 trialerror 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.
[pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? (Bugzilla reports Zarro Boogs found [2] and I didn't notice any issue/bug blocks in the latest ED). -Thanks, Art [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---
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 Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. (Bugzilla reports Zarro Boogs found [2] and I didn't notice any issue/bug blocks in the latest ED). -Thanks, Art [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---