[Bug 26492] New: IndexedDB: add/put/update operations should define ordering of clone vs. keypath evaluation

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

            Bug ID: 26492
           Summary: IndexedDB: add/put/update operations should define
                    ordering of clone vs. keypath evaluation
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
          Assignee: dave.null@w3.org
          Reporter: jsbell@google.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

We recently fixed a bug in Chromium, but it looks like it affects Firefox as
well and is implicit in the web-platform-tests suite (key_invalid.htm)

var store = db.createObjectStore('store', {keyPath: 'keypath'});
var values = ['string1', 'string2'];
var obj = { get keypath() { return values.shift(); } };

store.put(obj);
store.openCursor().onsuccess = function(e) {
  console.log('key is: ' + e.target.result.key);
  console.log('value has: ' + JSON.stringify(e.target.result.value.keypath));
};

In FF33 the key is 'string1' and the value has 'string2'. Having these out of
sync seems like a violation of the intent of the spec, although the letter of
the spec does imply tests before cloning.

In Chromium (circa 38) we clone, then evaluate the keypaths, so the result is
'string1' / 'string1'. 

This manifests in the key_invalid.htm test since it provides invalid key values
such as function(){}. In Chromium we return DataCloneError since we clone
before evaluating, whereas the test looks for DataError since it assumes
evaluation before cloning.

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

Received on Thursday, 31 July 2014 23:45:20 UTC