[Bug 20582] Definitions of "valid key" and key comparison are underdefined and not compatible with WebIDL

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20582

--- Comment #3 from Boris Zbarsky <bzbarsky@mit.edu> ---
Structured cloning is defined to work on ES values, not on WebIDL values last I
checked.  If it doesn't say that clearly, it really should.  When it says Array
it means it the way it's meant in ECMA-262: things whose internal [[Class]] is
Array.

I would probably be OK with IndexedDB clearly defining that it's working on ES
values, and really has nothing to do with WebIDL.  It's mixing the two that's a
problem, since getting a WebIDL anything out of an ES value involves
type-coercion in various ways.

> 3) getters - the structured clone algorithm is similarly underdefined here, 

How so?  It seems quite clearly defined.  It describes the exact order in which
you call getters on all the objects it operates on, assuming that your
enumeration order is defined.  All structured cloning does is enumerate all the
properties and grab their values.  It doesn't try to talk about anything being
defined, or any constraints on property values.  It also clearly defines cycle
handling and such.

> 4) toString/valueOf - the structured clone algorithm distinguishes between
> Objects, and primitive values

This is easy to do in the ES context.  WebIDL doesn't so much have great tools
for this, though "any" can represent the difference in some cases.  You just
have to be a little careful how you state things.

> 6, 7) comparison - I believe all implementations act AS IF they have
> performed a structured clone on the key value after validity is asserted and
> the clone is used rather than the original object for all further operations.

OK.  If that's how it works and if the spec explicitly defines the exact point
in time when the structured clones happen, that would resolve issues 6 and 7. 
There is no problem with structured cloning here; it already completely defines
order of operations, to the extent to which enumeration order is defined.

> #1, #2, #4 and #5 still bypass WebIDL

I don't think it's a problem per se as long as they do so consistently.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 9 January 2013 02:19:55 UTC