Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

2012-10-03 Thread Jonas Sicking 
On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell  wrote:
> On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal  wrote:
>>
>> So, at work and with the spec in front of me :-)
>>
>>
>> Odin claimed:
>>
>>> There is a note near the algorithm saying something to that point, but
>>> the definite text is up in the prose "let's explain IDB" section IIRC.
>>
>>
>> Nope, this was wrong, it's actually right there in the algorithm:
>>
>>
>> 
>>
>> # If direction is "prevunique", let temp record be the last record in
>> # records which satisfy all of the following requirements:
>> #
>> #   If key is defined, the record's key is less than or equal to key.
>> #   If position is defined, the record's key is less than position.
>> #   If range is defined, the record's key is in range.
>> #
>> # If temp record is defined, let found record be the first record in
>> # records whose key is equal to temp record's key
>>
>> So it'll find the last "foo", and then, as the last step, it'll find the
>> top result for "foo", giving id 1, not 3. The prevunique is the only algo
>> that uses that temporary record to do its search.
>>
>> I remember this text was somewhat different before, I think someone
>> clarified it at some point. At least it seems much clearer to me now than
>> it did the first time.
>
>
> Since I have it the link handy - discussed/resolved at:
>
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.html
>
>>
>> Israel Hilerio said:
>>>
>>> Since we’re seeing this behavior in both browsers (FF and Canary) we
>>> wanted to validate that this is not by design.
>>
>>
>> It would bet several pennies its by design, because the spec needs more
>> framework to explain this than it would've needed otherwise. What that
>> exact design was (rationale et al) I don't know, it was before my time I
>> guess. :-)
>
>
> Yes, the behavior in Chrome is by design to match list consensus.
>
> (FWIW, it's extra code to handle this case, and we've had bug reports where
> we had to point at the spec to explain that we're actually following it, but
> presumably this is one of those cases where someone will be confused by the
> results regardless of which approach was taken.)

Yes, this was very intentional. The goal was that reverse iteration
would always return the same set of rows as forward iteration, just in
reverse order. This seemed like the most easily understandable and
explainable behavior.

Consider for example a UI which renders an address book grouped by
first letter and showing the first name in that letter. It would seem
strange if the user changing z-a or a-z shows different names.

/ Jonas

CfC: publish WD of Shadow DOM; deadline Oct 10

2012-10-03 Thread Arthur Barstow 
Dimitri would like to publish a new Working Draft of Shadow DOM and this 
is a Call for Consensus to do so, using the following document as the 
basis 
.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by October 10 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, AB

Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

2012-10-03 Thread Joshua Bell 
On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal  wrote:

> So, at work and with the spec in front of me :-)
>
>
> Odin claimed:
>
>  There is a note near the algorithm saying something to that point, but
>> the definite text is up in the prose "let's explain IDB" section IIRC.
>>
>
> Nope, this was wrong, it's actually right there in the algorithm:
>
>    Overview.html#dfn-steps-for-**iterating-a-cursor
> >
>
> # If direction is "prevunique", let temp record be the last record in
> # records which satisfy all of the following requirements:
> #
> #   If key is defined, the record's key is less than or equal to key.
> #   If position is defined, the record's key is less than position.
> #   If range is defined, the record's key is in range.
> #
> # If temp record is defined, let found record be the first record in
> # records whose key is equal to temp record's key
>
> So it'll find the last "foo", and then, as the last step, it'll find the
> top result for "foo", giving id 1, not 3. The prevunique is the only algo
> that uses that temporary record to do its search.
>
> I remember this text was somewhat different before, I think someone
> clarified it at some point. At least it seems much clearer to me now than
> it did the first time.


Since I have it the link handy - discussed/resolved at:

http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.html


> Israel Hilerio said:
>
>> Since we’re seeing this behavior in both browsers (FF and Canary) we
>> wanted to validate that this is not by design.
>>
>
> It would bet several pennies its by design, because the spec needs more
> framework to explain this than it would've needed otherwise. What that
> exact design was (rationale et al) I don't know, it was before my time I
> guess. :-)


Yes, the behavior in Chrome is by design to match list consensus.

(FWIW, it's extra code to handle this case, and we've had bug reports where
we had to point at the spec to explain that we're actually following it,
but presumably this is one of those cases where someone will be confused by
the results regardless of which approach was taken.)

Re: [WebIDL] Interface object prototype and function object

2012-10-03 Thread Boris Zbarsky 

On 10/3/12 11:43 AM, Philippe Le Hegaret wrote:

In
  http://dev.w3.org/2006/webapi/WebIDL/

section 4.4.1 says: "The interface object for a given non-callback
interface is a function object."

section 4 says: "If an object is defined to be a function object, then
it has characteristics as follows: Its [[Prototype]] internal property
is the Function prototype object.[...]"

Does this mean that:
  typeof Document.prototype should return "function" ?

If not, I'm wondering what I'm missing...


It means that "Object.getPrototypeOf(Document) === Function.prototype" 
should test true.


I'm not quite sure what you're missing, because I don't understand how 
you went from "[[Prototype]] internal property" to ".prototype".


-Boris

Re: [WebIDL] Interface object prototype and function object

2012-10-03 Thread Ms2ger 

Hi Philippe,

On 10/03/2012 05:43 PM, Philippe Le Hegaret wrote:

In
  http://dev.w3.org/2006/webapi/WebIDL/

section 4.4.1 says: "The interface object for a given non-callback
interface is a function object."

section 4 says: "If an object is defined to be a function object, then
it has characteristics as follows: Its [[Prototype]] internal property
is the Function prototype object.[...]"

Does this mean that:
  typeof Document.prototype should return "function" ?

If not, I'm wondering what I'm missing...


What you're missing is that obj.prototype doesn't return obj's 
[[Prototype]] internal property. You can get the [[Prototype]] internal 
property through Object.getPrototypeOf(obj) or obj.__proto__. In Gecko, 
at least,


w(typeof XMLHttpRequest)
w(typeof Object.getPrototypeOf(XMLHttpRequest))
w(typeof XMLHttpRequest.__proto__)

all print "function". (Using XMLHttpRequest because that's one of the 
few objects that use WebIDL-compliant bindings in Gecko.)


HTH
Ms2ger

[WebIDL] Interface object prototype and function object

2012-10-03 Thread Philippe Le Hegaret 
In
 http://dev.w3.org/2006/webapi/WebIDL/

section 4.4.1 says: "The interface object for a given non-callback
interface is a function object."

section 4 says: "If an object is defined to be a function object, then
it has characteristics as follows: Its [[Prototype]] internal property
is the Function prototype object.[...]"

Does this mean that:
 typeof Document.prototype should return "function" ?

If not, I'm wondering what I'm missing...

Philippe

Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

2012-10-03 Thread Odin Hørthe Omdal 

So, at work and with the spec in front of me :-)


Odin claimed:
There is a note near the algorithm saying something to that point, but  
the definite text is up in the prose "let's explain IDB" section IIRC.


Nope, this was wrong, it's actually right there in the algorithm:

  


# If direction is "prevunique", let temp record be the last record in
# records which satisfy all of the following requirements:
#
#   If key is defined, the record's key is less than or equal to key.
#   If position is defined, the record's key is less than position.
#   If range is defined, the record's key is in range.
#
# If temp record is defined, let found record be the first record in
# records whose key is equal to temp record's key

So it'll find the last "foo", and then, as the last step, it'll find the
top result for "foo", giving id 1, not 3. The prevunique is the only algo
that uses that temporary record to do its search.

I remember this text was somewhat different before, I think someone
clarified it at some point. At least it seems much clearer to me now than
it did the first time.


Israel Hilerio said:
Since we’re seeing this behavior in both browsers (FF and Canary) we  
wanted to validate that this is not by design.


It would bet several pennies its by design, because the spec needs more
framework to explain this than it would've needed otherwise. What that
exact design was (rationale et al) I don't know, it was before my time I
guess. :-)

--
HØRTHE OMDAL, ODIN* Velmont/odinho · Core, Opera Software, http://opera.com

*: Sorry sorry sorry for top-posting in my previous phone-sent email.
  My in-email excuse wasn't accepted, and I received flames and punishment
  when I came to work. I apologize for littering your inboxes.

Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

2012-10-03 Thread Odin Hørthe Omdal 
Without checking (I'm waiting for the bus in the rain) I can say we also do it 
like this. It is actually in the spec if you read it dead carefully, it's just 
not that obvious.

It will first do the range getting, and then it will take the item on top 
sorted secondarily by value. And in an index the «value» is actually the key to 
the primary record.

There is a note near the algorithm saying something to that point, but the 
definite text is up in the prose "let's explain IDB" section IIRC.

It's not really clear IMHO. I believe I have written a few tests for it.

Standard early morning not yet at work and without the spec in front of me 
disclaimer :)

--

Sent from my N9, excuse the top posting



On 03.10.12 03:37 Israel Hilerio wrote:

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