https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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
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
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
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
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
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,
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 =
10 matches
Mail list logo
