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

RE: [indexeddb] Keypath attribute lookup question

From: Israel Hilerio <israelh@microsoft.com>
Date: Sat, 12 Nov 2011 01:07:00 +0000
To: Joshua Bell <jsbell@chromium.org>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F54BFE2@TK5EX14MBXC117.redmond.corp.microsoft.com>
On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote:
>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.

What you're saying makes sense!  The scenario we are worried about is the one in which we want to be able to index on the size, type, name, and lastModifiedDate attributes of a File object.  Given the current SCA serialization logic, I'm not sure this is directly supported.  This could become an interoperable problem if we allow these properties to be serialized and indexed in our implementation but FF or Chrome don't. We consider Blobs and Files to be host objects and we treat those a little different from regular JavaScript Objects. 

We feel that the ability to index these properties enables many useful scenarios and would like to see all browsers support it.

What do you and Jonas think?

Received on Saturday, 12 November 2011 01:07:29 UTC

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