GitLab

Stores with (1) a keyPath (a.k.a. inline keys) and (2) autoIncrement
(a.k.a. a key generator) have primary keys generated by the browser
and inserted into objects lazily, since the renderer doesn't know what
the primary keys will be when the object is serialized.

Indexes might have a keyPath that references the same spot in the
object. This is handled by checking if the keypaths match. If so,
the browser synthesizes the index key (same as the primary key). But
Chrome was not handling the case where the index had a compound
key - a keypath that's an array, plucking multiple values out of
the object. An object with unresolved keypaths would normally just
not be indexed, per spec. But since the primary keys should be injected
before the indexing occurs, these should be indexed.

Fix this by sending the index keys from the renderer to the browser
as an array with "holes" that need to be filled in.

This is covered by an existing Web Platform Test, which we now pass.

Bug: 701972
Change-Id: I14940b23cfcbb7f8b673143b402f574220184fd7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1728058
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Chase Phillips <cmp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#692313}