W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [indexeddb] Keypath attribute lookup question

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 9 Nov 2011 16:46:52 -0800
Message-ID: <CAD649j4LdHGqjZfgRSDyRifeEFhyVv0uYsgv_L_B55UwZVF9vQ@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio <israelh@microsoft.com>wrote:

> In section "4.7 Steps for extracting a key from a value using a key path"
> step #4 it states that:
> * If object does not have an attribute named attribute, then skip the rest
> of these steps and no value is returned.
> We want to verify that the attribute lookup is taking place on the
> immediate object attributes and the prototype chain, correct?

My reading of the spec: In 3.2.5 the description of add (etc) says that the
method creates a structured clone of value then runs the store operation
with that cloned value. The steps for storing a record (5.1) are the
context where the key path is evaluated, which would imply that it is done
against the cloned value. The structured cloning algorithm doesn't walk the
prototype chain, so this reading would indicate that the attribute lookup
only occurs against the immediate object.

I believe there's a spec issue in that in section 3.2.5 the list of cases
where DataError is thrown are described without reference to the value
parameter (it's implied, but not stated), followed by "Otherwise this
method creates a structured clone of the value parameter". That implies
that these error cases apply to the value, whereas the storage operations
apply to the structured clone of the value. (TOCTOU?)

We (Chrome) believe that the structured clone step should occur prior to
the checks and the cloned value be used for these operations.
Received on Thursday, 10 November 2011 00:47:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC