[Bug 21555] Use of IDL arrays for keyPath values is underdefined

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

--- Comment #2 from Joshua Bell <jsbell@chromium.org> ---
(In reply to comment #1)
> So I guess the first question is whether the return value should be a new
> object each time or the same object each time in cases when the keyPath is
> not just a string.  Generally having it be a new object each time is bad
> form for an attribute.

Agreed. (I believe there was some mailing list churn about adding an IDL
attribute for this?) 

IDBCursor.value has this explicitly:

"Note that if this property returns an object, it returns the same object
instance every time it is inspected, until the cursor's value is changed. This
means that if the object is modified, those modifications will be seen by
anyone inspecting the value of the cursor. However modifying such an object
does not modify the contents of the database."

Wordy; it'd be nice to have a way to express this succinctly in the IDL. (Also,
since it's normative, we should probably ditch the "Note that")

(In reply to comment #0)
> (except that IDBIndex is missing the "or") and prose that says:

Fixed, thanks. https://dvcs.w3.org/hg/IndexedDB/rev/f3da35b35633

> In terms of UA behavior, what Gecko does, based on code inspection, is that
> it creates an actual JS Array object when you first do .keyPath, and hands
> it out.  After that it keeps handing out the same Array object every time. 
> The script that got it can modify the Array object, and the modifications
> have no effect on anything other than what other .keyPath getters see.

FWIW, I prefer Gecko's behavior, and I think we can switch Chrome over to that.

For reference, in IE10 createIndex("name", ["a", "b"]).keyPath yields the
string "a,b". (ISTR that IE10 does not support array-type key paths.)

> Both behaviors seem fairly broken to me, for what it's worth, neither one
> matches the current IDL in the spec, and the current spec can't be
> interoperably implemented given just the information in it anyway....

Reading the WebIDL spec, it seems that the Gecko behavior could be described by
altering the prose to say:

"This will be either a DOMString, a variable length DOMString array or null. If
this property returns an array, it returns the same instance on every access to
the property, and modifications to the array have no affect on the object
store."

Is that sufficient?

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

Received on Tuesday, 2 April 2013 18:43:33 UTC