Re: IndexedDB: Extra properties in optionalParameters objects

2012-01-24 Thread Cameron McCormack

Joshua Bell:

By my reading of the IDB and WebIDL specs, the optionalParameters
parameter is a WebIDL dictionary
(http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
binding algorithm for WebIDL dictionaries
(http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
expected in the IDL dictionary are read out of the ECMAScript object,
but the properties of the ECMAScript object itself are never enumerated
and therefore "extra" properties should be ignored. Therefore, the
"parameter" property in the test code would be ignored, and this would
be treated the same as db.createObjectStore(name, {}) which should not
produce an error.


That's right.



Re: IndexedDB: Extra properties in optionalParameters objects

2012-01-24 Thread Jonas Sicking
On Tue, Jan 24, 2012 at 2:36 PM, Joshua Bell  wrote:
> I noticed a test regarding optional parameters
> on http://samples.msdn.microsoft.com/ietestcenter/#indexeddb that IE10PP4
> and Chrome 15 are marked as failing and Firefox 8 is marked as passing. (I
> have Chrome 18 and FF9 handy - no changes.)
>
> The specific test is "IDBDatabase.createObjectStore() - attempt to create an
> object store with an invalid optional parameter"
> at http://samples.msdn.microsoft.com/ietestcenter/indexeddb/indexeddb_harness.htm?url=idbdatabase_createObjectStore7.htm and
> the actual JavaScript code that's being tested:
>
> objStore = db.createObjectStore(objectStoreName, { parameter: 0 });
>
>
> By my reading of the IDB and WebIDL specs, the optionalParameters parameter
> is a WebIDL dictionary
> (http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
> binding algorithm for WebIDL dictionaries
> (http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
> expected in the IDL dictionary are read out of the ECMAScript object, but
> the properties of the ECMAScript object itself are never enumerated and
> therefore "extra" properties should be ignored. Therefore, the "parameter"
> property in the test code would be ignored, and this would be treated the
> same as db.createObjectStore(name, {}) which should not produce an error.
>
> So I would consider the IE10 and Chrome behavior correct, and the test
> itself and Firefox behavior incorrect.
>
> Thoughts?

Yup. We made this change in the spec a while ago (I was the one who
was pushing for the throwing behavior, but eventually gave in). The
change was made by switching to using WebIDL dictionaries which behave
exactly as you describe.

This has also been fixed in newer versions of Firefox. This is fixed
in Firefox 10 which will be released very soon (a week or two).

/ Jonas



IndexedDB: Extra properties in optionalParameters objects

2012-01-24 Thread Joshua Bell
I noticed a test regarding optional parameters on
http://samples.msdn.microsoft.com/ietestcenter/#indexeddb that IE10PP4 and
Chrome 15 are marked as failing and Firefox 8 is marked as passing. (I have
Chrome 18 and FF9 handy - no changes.)

The specific test is "IDBDatabase.createObjectStore() - attempt to create
an object store with an invalid optional parameter" at
http://samples.msdn.microsoft.com/ietestcenter/indexeddb/indexeddb_harness.htm?url=idbdatabase_createObjectStore7.htm
and
the actual JavaScript code that's being tested:

objStore = db.createObjectStore(objectStoreName, { parameter: 0 });


By my reading of the IDB and WebIDL specs, the optionalParameters parameter
is a WebIDL dictionary (
http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
binding algorithm for WebIDL dictionaries (
http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
expected in the IDL dictionary are read out of the ECMAScript object, but
the properties of the ECMAScript object itself are never enumerated and
therefore "extra" properties should be ignored. Therefore, the "parameter"
property in the test code would be ignored, and this would be treated the
same as db.createObjectStore(name, {}) which should not produce an error.

So I would consider the IE10 and Chrome behavior correct, and the test
itself and Firefox behavior incorrect.

Thoughts?