Bug 76075 - IndexedDB: Invalid keys yielded by key paths should raise exceptions, not error callbacks
Summary: IndexedDB: Invalid keys yielded by key paths should raise exceptions, not err...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Joshua Bell
URL:
Keywords:
Depends on:
Blocks: 76198
  Show dependency treegraph
 
Reported: 2012-01-11 10:21 PST by Joshua Bell
Modified: 2012-01-18 21:00 PST (History)
5 users (show)

See Also:


Attachments
Patch (20.19 KB, patch)
2012-01-12 12:49 PST, Joshua Bell
no flags Details | Formatted Diff | Diff
Patch (12.54 KB, patch)
2012-01-17 15:51 PST, Joshua Bell
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2012-01-11 10:21:46 PST
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.
Comment 1 Joshua Bell 2012-01-11 10:27:23 PST
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.
Comment 2 Joshua Bell 2012-01-12 12:49:24 PST
Created attachment 122292 [details]
Patch
Comment 3 Joshua Bell 2012-01-12 14:10:57 PST
Comment on attachment 122292 [details]
Patch

Failing browser tests, need to dig further
Comment 4 Joshua Bell 2012-01-12 17:16:38 PST
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.
Comment 5 Joshua Bell 2012-01-17 15:51:58 PST
Created attachment 122830 [details]
Patch
Comment 6 Joshua Bell 2012-01-17 15:52:51 PST
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.)
Comment 7 Joshua Bell 2012-01-18 10:08:35 PST
tony@, can you r?
Comment 8 WebKit Review Bot 2012-01-18 14:36:29 PST
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 9 WebKit Review Bot 2012-01-18 14:59:12 PST
Comment on attachment 122830 [details]
Patch

Clearing flags on attachment: 122830

Committed r105329: <http://trac.webkit.org/changeset/105329>
Comment 10 WebKit Review Bot 2012-01-18 14:59:17 PST
All reviewed patches have been landed.  Closing bug.
Comment 11 Roland Steiner 2012-01-18 20:54:29 PST
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())" ?
Comment 12 Roland Steiner 2012-01-18 20:54:51 PST
(rolled out)
Comment 13 Roland Steiner 2012-01-18 20:59:04 PST
ARGH, wrong bug entry, please ignore comments 11 & 12... >_<
Comment 14 Joshua Bell 2012-01-18 21:00:55 PST
(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.