[Bug 17264] Add attributes to use ping/pong frames effectively
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Comment #12 from Ian 'Hixie' Hickson i...@hixie.ch 2012-10-02 19:16:01 UTC --- Marking this LATER to separate it from more urgent bugs; will reopen and reconsider in January. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
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.
[IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor
We noticed there is consistent behavior between FF v.15.0.1 and Chrome
v.24.0.1284.0 canary that we believe is a bug when dealing with both
'prevunique' and 'nextunique'. Below is what we're seeing using the following
site http://jsbin.com/iyobis/10/edit
For the following data set (keypath = 'id')
{id:1, a: 'foo' };
{id:2, a: 'bar' };
{id:3, a: 'foo' };
When we open the cursor with prevunique and nextunique, on an index on 'a'
using IDBKeyRnage.only('foo') we get the following record back:
{id:1, a: 'foo' };
For the data above, it seems like there should be different return values for
prevunique and nextunique based on the definitions on the spec.
Our expectation was that for prevunique we would get the following record:
{id:3, a: 'foo' };
The reason being that the bottom of our index list starts with id:3.
And for nextunique we would get the following record:
{id:1, a: 'foo' };
The reason being that the top of our index list starts with id:1.
Since we're seeing this behavior in both browsers (FF and Canary) we wanted to
validate that this is not by design.
Can you confirm?
Thanks,
Israel
