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

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

            Bug ID: 21555
           Summary: Use of IDL arrays for keyPath values is underdefined
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
          Assignee: dave.null@w3.org
          Reporter: bzbarsky@mit.edu
        QA Contact: public-webapps-bugzilla@w3.org
                CC: cam@mcc.id.au, jsbell@chromium.org, mike@w3.org,
                    public-webapps@w3.org

There are several uses of IDL arrays in IndexedDB API.  Specifically,
IDBObjectStore.keyPath, IDBIndex.keyPath, IDBObjectStoreSync.keyPath, and
IDBIndexSync.keyPath.

All of these have the same general structure.  The IDL looks sort of like this:

    readonly    attribute (DOMString or DOMString[])? keyPath;

(except that IDBIndex is missing the "or") and prose that says:

     On getting, returns the key path of this object store. This will be either
     a DOMString, an Array of DOMStrings or null. 

(without the bits about null for the IDBIndex/IDBIndexSync, since those are not
nullable).

Unfortunately:

1)  An IDL array is not in fact a JS Array, so the prose is wrong in claiming
    that an Array is returned.

2)  Simply declaring something to be an IDL array in the IDL does not define
    its behavior.  Specifically, there are three different types of IDL arrays:
    fixed length, variable length, and readonly.  Which one is being returned
    here needs to be defined in the prose.  What happens on writes if the array
    is not readonly also needs to be defined in the prose.

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.

What Chrome does is to return a DOMStringList.  Furthermore, it returns a new
DOMStringList every time, so doing this:

  alert(store.keyPath == store.keyPath);

in Chrome alerts false.

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....

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

Received on Tuesday, 2 April 2013 18:07:52 UTC