Bug 76487

Following on from: https://bugs.webkit.org/show_bug.cgi?id=76075 There are some subtleties in the IDB spec: * The object store uses in-line keys and the result of evaluating the object store's key path yields a value and that value is not a valid key. * If there are any indexes referencing this object store whose key path is a string, evaluating their key path on the value parameter yields a value, and that value is not a valid key. To implement these we need to ensure the fetchKeyFromKeyPath() functions distinguish the two cases: * key path does not yield a value * key path yields a value which is not a valid key The obvious way to do this is have the function return NULL vs. an IDBKey (which has InvalidType). Unfortunately, these distinct cases are not represented in the WebKit API for the chromium port - Source/chromium/src/WebIDBKey.cpp collapses the two cases. The behavior difference is really only notable for adding/putting object store records where there is an index. When the index's keyPath yields nothing then the index doesn't get an entry for that object store record. When the index's keyPath yields a value but that value is not a valid key the spec indicates the add/put call should raise an exception. Currently, the storage/indexeddb/objectstore-basics.html test fails on this in the Chromium port: store = db.createObjectStore('storeName', null) index = store.createIndex('indexName', 'x', {unique: true}) ... transaction = db.transaction(['storeName'], webkitIDBTransaction.READ_WRITE) store = transaction.objectStore('storeName') request = store.add({x: null}, 'validkey') The last line should, per spec, throw DATA_ERR (see https://bugs.webkit.org/show_bug.cgi?id=76075). The current implementation checks later and thus fails the request, sending an Error event - this works in DumpRenderTree. In Chromium the request succeeds.