Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype We could say that the clone created when storing in the database is created in a separate global scope. / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties.
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). In terms of the behavior we care about they're the same. In terms of finely specifying how we evaluate keypaths: String values and String objects are different beasts, e.g. length in [1,2,3] -- true, length in abc -- TypeError, length in new String(abc) -- true. It turns out that abc.length is short for Object(abc).length which in turn is (new String(abc)).length which is really (new String(abc))[length]. So putting on the pedantic hat, string doesn't have any properties, it just behaves like it does c/o the fine grained rules of the [] operation in ECMAScript. Wheee.
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 2:20 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). In terms of the behavior we care about they're the same. In terms of finely specifying how we evaluate keypaths: String values and String objects are different beasts, e.g. length in [1,2,3] -- true, length in abc -- TypeError, length in new String(abc) -- true. It turns out that abc.length is short for Object(abc).length which in turn is (new String(abc)).length which is really (new String(abc))[length]. So putting on the pedantic hat, string doesn't have any properties, it just behaves like it does c/o the fine grained rules of the [] operation in ECMAScript. Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. Those are on the Number object itself, not Number.prototype and hence not inherited by instances of Number, so you can't do (1).NEGATIVE_INFINITY. You can't structured-clone Number itself (it's a function); you probably could structured-clone Math, but the behavior would be predictable (either the properties would clone or they wouldn't, but the resulting object would be distinct from the global Math object itself). It's just the sections Properties of XXX Instances and Properties of the XXX Prototype Object that we need to worry about. The others are functions - while these would exist in the theoretical new global context, they aren't valid keys. So I think the Array and String length properties are the only interesting cases. Good point, i missed the fact that the properties are on Number and not on Number. So even defining it as a plan property lookup would give the same behavior as below. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length That would certainly make conformance testing a lot easier. +1 from me. Sounds good. / Jonas
RE: [indexeddb] Keypath attribute lookup question
On Tuesday, November 15, 2011 4:33 PM, Jonas Sicking wrote: On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. Those are on the Number object itself, not Number.prototype and hence not inherited by instances of Number, so you can't do (1).NEGATIVE_INFINITY. You can't structured-clone Number itself (it's a function); you probably could structured-clone Math, but the behavior would be predictable (either the properties would clone or they wouldn't, but the resulting object would be distinct from the global Math object itself). It's just the sections Properties of XXX Instances and Properties of the XXX Prototype Object that we need to worry about. The others are functions - while these would exist in the theoretical new global context, they aren't valid keys. So I think the Array and String length properties are the only interesting cases. Good point, i missed the fact that the properties are on Number and not on Number. So even defining it as a plan property lookup would give the same behavior as below. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length That would certainly make conformance testing a lot easier. +1 from me. Sounds good. This is the outcome we were hoping for. Do we need to add anything to the IDB spec to capture this behavior or is already covered (perhaps a note)? Israel / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Sat, Nov 12, 2011 at 2:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Nov 11, 2011 at 5:07 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote: On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@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? Wow, good points all around. My concern about getting properties off of the structured clone is one of performance. Currently when we do a structured clone we actually simply serialize the object graph. Serializing needs to happen anyway so we might as well do it as part of structured cloning. Turns out this is the case in basically *all* APIs which use structured clones, that they need to both clone and serialize, so this has worked great as an implementation strategy, both for code reuse and performance reasons. So my concern is that if we get the properties off of the structured clone, then it means getting them not from an object graph, but from a serialized thing. I also concur with Israel's comment. Though this seems solvable by simply adding more smarts to the code which reads the values from the serialized thing as to make it support native objects. We have the exact same issue as microsoft here. On the flip side, I definitely see a risk if we get the index values from the object prior to structured clone. This could prevent optimizations such as being able to read out the index values on the database thread. This could be useful when deleting an item from the objectStore so that the relevant values from all indexes can be removed. I'll have to confer with other people at mozilla before expressing a too strong opinion either way here. I talked this over with people that knows our structured clone implementation better than me. As I see it, the main question is if we should do the index-value lookup on the value handed to the .put/.add/.update function, or if we should do the lookup on the structured clone of that value. I.e. if someone calls objectStore.add(X); we will before the .add function returns, create a structured clone of the value in X. The question is if we should look up index values on X, or on the structured clone of X. There are several behavioral differences between the two. For example if any values on X are implemented using getters, then those getters might return different things when the structured clone is happening, and when the index-value-getting code is executing. Another difference is that for any non-host object, any values that live on the prototype chain get lost during the structured clone since it doesn't copy the prototype chain. What I think we should do is to get index values from the structured clone of X. There at least two advantages of this: 1. The code to get index values can run on the database thread of the IDB implementation. This enables a more parallel implementation.
Re: [indexeddb] Keypath attribute lookup question
On Fri, Nov 11, 2011 at 5:07 PM, Israel Hilerio isra...@microsoft.comwrote: On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote: On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@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? That's a good scenario. I think this works and both of our concerns/scenarios are satisfied if we mandate that the structured clone occurs first. Our concern is that the value can be captured at the time the method is called, both to avoid TOCTOU issues with the value changing after the call (either by directly mutating or having the prototype chain mutating) and to allow the value to be moved across process boundaries efficiently. For regular JS objects the clone is a snapshot of the object's properties, without the prototype chain, which satisfies this concern. Per http://www.w3.org/TR/html5/common-dom-interfaces.html#internal-structured-cloning-algorithm the structured clone of a File (or other explicitly-spec-sanctioned host object) is also a File (...) with the same data - the concern is also satisfied. To avoid TOCTOU issues and thinking about ECMAScript edge cases, I think we still want to mandate that the keypath evaluation does not walk the prototype chain, e.g. a keypath of foo should not inspect the value of Object.prototype.foo as that could change during the course of an asynchronous operation - and that async operation could be executing in a different process! Given all of that, accessing properties of host objects may need to be special cased if those would be considered walking the prototype chain (but I'm not sure they are, will have to think/dig further) So, in summary: 1. Snapshot first for predictable behavior 2. Don't walk the prototype chain, even though 1 precludes prototypes other than Object.prototype 3. Host objects attribute access may need to be special cased if that runs afoul of 1 or 2. Thoughts?
Re: [indexeddb] Keypath attribute lookup question
On Fri, Nov 11, 2011 at 5:07 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote: On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@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? Wow, good points all around. My concern about getting properties off of the structured clone is one of performance. Currently when we do a structured clone we actually simply serialize the object graph. Serializing needs to happen anyway so we might as well do it as part of structured cloning. Turns out this is the case in basically *all* APIs which use structured clones, that they need to both clone and serialize, so this has worked great as an implementation strategy, both for code reuse and performance reasons. So my concern is that if we get the properties off of the structured clone, then it means getting them not from an object graph, but from a serialized thing. I also concur with Israel's comment. Though this seems solvable by simply adding more smarts to the code which reads the values from the serialized thing as to make it support native objects. We have the exact same issue as microsoft here. On the flip side, I definitely see a risk if we get the index values from the object prior to structured clone. This could prevent optimizations such as being able to read out the index values on the database thread. This could be useful when deleting an item from the objectStore so that the relevant values from all indexes can be removed. I'll have to confer with other people at mozilla before expressing a too strong opinion either way here. / Jonas
RE: [indexeddb] Keypath attribute lookup question
On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote: On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@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? Israel
[indexeddb] Keypath attribute lookup question
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? Thanks, Israel
