Basic repro: var invalidKey = {}; var store = db.createObjectStore("storeName", {keyPath: "key"}); var request = store.put({key: invalidKey}); Expected: Exception thrown by store.put() call Actual: Error event raised on request object.
Applies to these clauses in the spec, which should occur synchronously prior to creation of the request: * 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. * If there are any indexes referencing this object store whose key path is an Array, evaluating any of the items in their key path on the value parameter yields a value and that value is not a valid key. In all of these cases we evaluate the keyPath during the asynchronous processing of the request during the transaction, not prior to the creation of the request.
Created attachment 122292 [details] Patch
Comment on attachment 122292 [details] Patch Failing browser tests, need to dig further
This ends up requiring the same plumbing changes for the Chromium port as 76116. We need to be able to send a "null" IDBKey* (i.e. no key) vs. an invalid key (i.e. a key was passed, but the value is invalid). Right now these can be distinguished within in WebCore, but the distinction is lost when they are sent through the chromium/src/WebIDBKey.h API - which is my fault from trying to clean up a while back. They collapse down to invalid, which trips a few APIs.
Created attachment 122830 [details] Patch
Comment on attachment 122830 [details] Patch Filed a new issue - https://bugs.webkit.org/show_bug.cgi?id=76487 - for the cases that will require additional plumbing. (Turns out we're already buggy there in the Chromium port.)
tony@, can you r?
Comment on attachment 122830 [details] Patch Rejecting attachment 122830 [details] from commit-queue. jsbell@chromium.org does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights.
Comment on attachment 122830 [details] Patch Clearing flags on attachment: 122830 Committed r105329: <http://trac.webkit.org/changeset/105329>
All reviewed patches have been landed. Closing bug.
Rolled out in r105376 as it broke the Chromium InjectIDBKey browser test. Also, I was wondering about the following part of the patch: + if (key && key->valid()) { + ec = IDBDatabaseException::DATA_ERR; + return; + } Should this be "if (key && ! key->valid())" ?
(rolled out)
ARGH, wrong bug entry, please ignore comments 11 & 12... >_<
(In reply to comment #11) > Rolled out in r105376 as it broke the Chromium InjectIDBKey browser test. Also, I was wondering about the following part of the patch: > > + if (key && key->valid()) { > + ec = IDBDatabaseException::DATA_ERR; > + return; > + } > > Should this be "if (key && ! key->valid())" ? Just for posterity: No, see https://bugs.webkit.org/show_bug.cgi?id=76487 - in the Chromium port, key always becomes valid after cross-process communication.