[Bug 17657] New: Empty arrays shouldn't be valid KeyPaths

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17657

   Summary: Empty arrays shouldn't be valid KeyPaths
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Something like createObjectStore("store", { keyPath: [] }) is completely
useless and so we should throw. Likewise for createIndex("index", [])

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [IndexedDB] Extracting keys and null/undefined

2012-06-29 Thread Jonas Sicking 
On Wed, Jun 20, 2012 at 6:24 AM, Kyle Huey  wrote:
> Consider an autoincrementing IDBObjectStore with keyPath "foo.bar".
>
> Which of the following (if any) should succeed?
>
> 1. objectStore.put({foo: null});
> 2. objectStore.put({foo: undefined});
> 3. objectStore.put({foo: {bar: null}});
> 4. objectStore.put({foo: {bar: undefined}});
>
> By my reading of the spec, currently #1 and #2 succeed, and #3 and #4 do
> not.

My reading of the spec is that all of the above fail.

> First, we look at the foo property on the object.  All 4 objects have a foo
> property.  We take the value of the foo property and consider that further.
> Then we look for a bar property.  Because 'null' and 'undefined' do not have
> that property, we return from step 5 of "the steps for extracting a key from
> a value using a key path" with no value for #1 and #2.  For #3 and #4, we
> return the value of the bar property, null or undefined, respectively.
> IDBObjectStore.put throws if, among other conditions, "the object store uses
> in-line keys and the result of evaluating the object store's key path yields
> a value and that value is not a valid key."  Since null and undefined are
> not valid keys, #3 and #4 are rejected,

With you so far. 3 and 4 throw due to yielding values which are not valid keys.

> while #1 and #2 go on to receive
> autogenerated keys.

#1 and #2 indeed go on to receive an autogenerated key. This happens
in section 5.1 step 2. This step invokes the algorithm defined in 4.14
in order to modify the value to insert the autogenerated key value.

The algorithm in 4.14 will in step 5 grab the 'foo' property which
will give us 'null' and 'undefined' respectively. We then go back up
to step 2. However this step will result in a DataError being thrown
since 'null' and 'undefined' aren't Object or Array objects.

Hence these will throw too.

(Looking at our tests, this appears to match Firefox behavior)

/ Jonas

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-29 Thread Jonas Sicking 
On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein  wrote:
> On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking  wrote:
>>
>> All in all I think that as soon as we introduce exceptions to when
>> MutationObserver callbacks fire we change the API from being a
>> reliable way to track DOM mutations to a unreliable way where all
>> callers have to be aware of exceptions and deal with them in other
>> ways. I.e. it feels like it significantly reduces the value of
>> MutationObservers.
>>
>> And so far I don't see any good arguments made for making that
>> reduction in value. Did I miss any arguments other then the randomness
>> argument?
>
>
> Performance was one concern that's come up in discussing this with Ojan and
> Rafael. Imagine a MutationObserver attached to the document near the top of
> the page. Now we need to create basically one MutationRecord per node
> inserted (because the parser operates in a depth-first sort of order). I'm
> not at all sure this is a show-stopper (we might be able to introduce some
> new MutationRecord type that could compactly represent parser-style
> operation), but it definitely seems worrisome, especially given that one of
> the common uses for MutationObservers is extensions which might run on many
> (all?) pages.

Hmm.. is there actually anything requiring that nodes are inserted one
at a time? Internally in mozilla we do insert nodes one at a time, but
the notifications we send out to the various subsystems make it seem
like nodes are inserted in big chunks. This has previously been to
give us good performance from the layout engine which benefits from
getting notified by large chunks being inserted rather than nodes
being inserted one at a time. The MutationObserver implementation
hangs off of the same notification system and thus also sees nodes as
being inserted in big chunks.

/ Jonas

RE: publish new WD of File API; deadline July 3

2012-06-29 Thread Adrian Bateman 
Microsoft supports this call.

On Tuesday, June 26, 2012 11:36 AM, Arthur Barstow wrote:
> Hi All - Arun is back to actively editing the File API spec and this is
> a Call for Consensus to publish a new WD of the spec. Please note that
> Arun will be committing some changes during this CfC and that the ED
> does not yet use the WD template:
> 
> 
> 
> Agreement to this proposal: a) indicates support for publishing a new
> WD; and b) does not necessarily indicate support of the contents of the WD.
> 
> If you have any comments or concerns about this proposal, please reply
> to this e-mail by July 3 at the latest.
> 
> Positive response to this CfC is preferred and encouraged and silence
> will be assumed to mean  agreement with the proposal.

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-29 Thread Adam Klein 
On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking  wrote:

> All in all I think that as soon as we introduce exceptions to when
> MutationObserver callbacks fire we change the API from being a
> reliable way to track DOM mutations to a unreliable way where all
> callers have to be aware of exceptions and deal with them in other
> ways. I.e. it feels like it significantly reduces the value of
> MutationObservers.
>
> And so far I don't see any good arguments made for making that
> reduction in value. Did I miss any arguments other then the randomness
> argument?
>

Performance was one concern that's come up in discussing this with Ojan and
Rafael. Imagine a MutationObserver attached to the document near the top of
the page. Now we need to create basically one MutationRecord per node
inserted (because the parser operates in a depth-first sort of order). I'm
not at all sure this is a show-stopper (we might be able to introduce some
new MutationRecord type that could compactly represent parser-style
operation), but it definitely seems worrisome, especially given that one of
the common uses for MutationObservers is extensions which might run on many
(all?) pages.

- Adam

Re: WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Joshua Bell 
On Fri, Jun 29, 2012 at 9:50 AM, Boris Zbarsky  wrote:

> On 6/29/12 12:25 PM, Joshua Bell wrote:
>
>> void f(float[] x); // overload A
>> void f(DOMString x); // overload B
>>
>> WebIDL itself, of course, doesn't dictate how matching and dispatching
>> should be implemented
>>
>
> Actually, it does. http://dev.w3.org/2006/webapi/**WebIDL/#dfn-overload-**
> resolution-algorithm
>
>
Ah, thank you! I'd missed that, mired in 3.2.6. Very happy to be wrong.


> The implication is that an IDL that defines methods
>> with signatures that are not distinguishable is invalid
>>
>
> Correct.
>
>
>  So rephrasing the question: are the above types distinguishable?
>>
>
> http://dev.w3.org/2006/webapi/**WebIDL/#dfn-distinguishableseems
>  pretty clear: yes.
>
>
>  And if so, which would be expected to handle the call:
>>
>> f(null);
>>
>> Several interpretations and hence outcomes occur to us
>>
>
> Per current spec, at http://dev.w3.org/2006/webapi/**WebIDL/#dfn-overload-
> **resolution-algorithmstep
>  13 we have:
>
> * Substep 2 is skipped because there are no nullable types or
>  dictionaries here.
> * Substeps 3-6 are skipped because null is not an object.
> * In step 7 the overload with DOMString is selected
>
>
>  (3) T[] does not match null, but as null is an ECMAScript primitive
>> value it is run through ToString() and hence overload B is invoked with
>> DOMString "null"
>>
>
> This is what happens per spec at the moment, but the fact that null is a
> primitive value is somewhat irrelevant except insofar as it makes it not
> match the preconditions in substep 4.


Agreed and agreed, thank you.

[Bug 17656] New: Rewrite Blob constructor algorithm

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17656

   Summary: Rewrite Blob constructor algorithm
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: ms2...@gmail.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


Created attachment 1150
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1150
Patch

It's an unreadable mess with a lot of hand-waving and at least one obvious bug
(it doesn't take into account blobParts[0]). Patch for the rewrite attached.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Kyle Huey 
On Fri, Jun 29, 2012 at 9:51 AM, Boris Zbarsky  wrote:

> On 6/29/12 12:37 PM, Kyle Huey wrote:
>
>> #5.  Neither T[] nor DOMString admits null as a value.
>>
>
> DOMString does not admit null as an IDL value.
>
> Which means that ES null is stringified when converting to DOMString.
>
> -Boris
>
> Ah yes, I forgot about that.

Thanks for the correction.

- Kyle

Re: WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Boris Zbarsky 

On 6/29/12 12:37 PM, Kyle Huey wrote:

#5.  Neither T[] nor DOMString admits null as a value.


DOMString does not admit null as an IDL value.

Which means that ES null is stringified when converting to DOMString.

-Boris

Re: WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Boris Zbarsky 

On 6/29/12 12:25 PM, Joshua Bell wrote:

void f(float[] x); // overload A
void f(DOMString x); // overload B

WebIDL itself, of course, doesn't dictate how matching and dispatching
should be implemented


Actually, it does. 
http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm



The implication is that an IDL that defines methods
with signatures that are not distinguishable is invalid


Correct.


So rephrasing the question: are the above types distinguishable?


http://dev.w3.org/2006/webapi/WebIDL/#dfn-distinguishable seems pretty 
clear: yes.



And if so, which would be expected to handle the call:

f(null);

Several interpretations and hence outcomes occur to us


Per current spec, at 
http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm 
step 13 we have:


* Substep 2 is skipped because there are no nullable types or
  dictionaries here.
* Substeps 3-6 are skipped because null is not an object.
* In step 7 the overload with DOMString is selected


(3) T[] does not match null, but as null is an ECMAScript primitive
value it is run through ToString() and hence overload B is invoked with
DOMString "null"


This is what happens per spec at the moment, but the fact that null is a 
primitive value is somewhat irrelevant except insofar as it makes it not 
match the preconditions in substep 4.


-Boris

Re: WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Kyle Huey 
On Fri, Jun 29, 2012 at 9:25 AM, Joshua Bell  wrote:

> Over in WebKit-land there's some disagreement about WebIDL method overload
> resolution, specifically around passing null, arrays (T[]) and the concept
> of Nullable.
>
> Here's an example where we're just not sure what the WebIDL spec dictates:
>
> void f(float[] x); // overload A
> void f(DOMString x); // overload B
>
> WebIDL itself, of course, doesn't dictate how matching and dispatching
> should be implemented; it instead defines whether types are
> distinguishable. The implication is that an IDL that defines methods with
> signatures that are not distinguishable is invalid, so it's a non-issue in
> terms of the spec. So rephrasing the question: are the above types
> distinguishable? And if so, which would be expected to handle the call:
>
> f(null);
>
> Several interpretations and hence outcomes occur to us, hopefully
> presented without indicating my particular bias:
>
> (1) T[] is inherently Nullable (i.e. T[] === T[]?), DOMString is not,
> overload A would be invoked with a null argument and the implementation is
> expected to handle this case
> (2) T[] accepts null but the IDL type to ECMAScript conversion rules
> produce an empty array; overload A is invoked with an empty float array
> (3) T[] does not match null, but as null is an ECMAScript primitive value
> it is run through ToString() and hence overload B is invoked with DOMString
> "null"
> (4) Either T[] or DOMString could match null, so types of the arguments
> are not distinguishable and hence the above is invalid WebIDL
> (5) Neither T[] nor DOMString is inherently Nullable, so a TypeError is
> thrown
>
> Anyone? (Cameron?)
>

#5.  Neither T[] nor DOMString admits null as a value.

"Note also that null is not a value of type DOMString. To allow null, a
nullable DOMString, written as DOMString? in IDL, needs to be used. "

http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString

"The T[] type is a parameterized type. The values of this type are non-null
references to arrays of values of type T."

http://dev.w3.org/2006/webapi/WebIDL/#idl-array

- Kyle

WebIDL overload resolution, arrays and Nullable

2012-06-29 Thread Joshua Bell 
Over in WebKit-land there's some disagreement about WebIDL method overload
resolution, specifically around passing null, arrays (T[]) and the concept
of Nullable.

Here's an example where we're just not sure what the WebIDL spec dictates:

void f(float[] x); // overload A
void f(DOMString x); // overload B

WebIDL itself, of course, doesn't dictate how matching and dispatching
should be implemented; it instead defines whether types are
distinguishable. The implication is that an IDL that defines methods with
signatures that are not distinguishable is invalid, so it's a non-issue in
terms of the spec. So rephrasing the question: are the above types
distinguishable? And if so, which would be expected to handle the call:

f(null);

Several interpretations and hence outcomes occur to us, hopefully presented
without indicating my particular bias:

(1) T[] is inherently Nullable (i.e. T[] === T[]?), DOMString is not,
overload A would be invoked with a null argument and the implementation is
expected to handle this case
(2) T[] accepts null but the IDL type to ECMAScript conversion rules
produce an empty array; overload A is invoked with an empty float array
(3) T[] does not match null, but as null is an ECMAScript primitive value
it is run through ToString() and hence overload B is invoked with DOMString
"null"
(4) Either T[] or DOMString could match null, so types of the arguments are
not distinguishable and hence the above is invalid WebIDL
(5) Neither T[] nor DOMString is inherently Nullable, so a TypeError is
thrown

Anyone? (Cameron?)

[Bug 17653] 撮影依頼 - ちくせいロケーションサービス「ちくロケ！」

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17653

Olli Pettay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b...@pettay.fi
 Resolution||INVALID

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 17652] New: Blob constructor: the blobParts array should probably not have nullable elements

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17652

   Summary: Blob constructor: the blobParts array should probably
not have nullable elements
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: ms2...@gmail.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


It's not clear to me why that should be supported or what it would do.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [IndexedDB] Exception inconsistency

2012-06-29 Thread Jonas Sicking 
On Wed, Jun 13, 2012 at 7:50 PM, Kyle Huey  wrote:
> If a keypath passed to createObjectStore fails certain constraints (not
> passing arrays or empty strings to autoIncrement) the spec says to throw an
> InvalidAccessError.
>
> If a keypath passed to createIndex fails constraints (an array keypath
> passed to a multientry index) the spec says to throw a NotSupportedError.
>
> Why are these not consistent?

Good catch.

We use InvalidAccessError everywhere else, so switching to
InvalidAccessError for index creation too seems like the easiest
solution.

It's unfortunate that both exception types exist since they basically
seem to have the same meaning. DOM Core seems to only fire
NotSupportedError, while HTML5 fires both types of errors. I didn't
check other specs.

/ Jonas

[Bug 17650] New: Make createIndex throw InvalidAccessError instead of NotSupportedError

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17650

   Summary: Make createIndex throw InvalidAccessError instead of
NotSupportedError
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org




-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 17649] New: Address WebIDL comments from Kyle Huey

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17649

   Summary: Address WebIDL comments from Kyle Huey
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1152.html

I'm not sure that we can address all of them, such as the enum ones, due to
limitations in ReSpec

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-29 Thread Jonas Sicking 
On Wed, Jun 27, 2012 at 3:31 PM, Olli Pettay  wrote:
> On 06/26/2012 11:58 PM, Adam Klein wrote:
>>
>> On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren > > wrote:
>>
>>
>>    On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay > > wrote:
>>     > end-of-microtask or end-of-task everywhere. And yes, some parsing /
>>     > networking details may unfortunately be exposed,
>>     > but in a way which should be quite random. Web devs just can't
>> really rely
>>     > on network packages to be delivered to parser in
>>     > some exact way.
>>
>>    I think the original solution we had to not expose parser mutations
>>    was better. Exposing this can lead to all kinds of subtle bugs that
>>    are hard to detect for developers.
>>
>>
>> I take it from your reply that you and I had the same view of what's
>> specced in DOM4.
>
>
> DOM4 doesn't say anything about this. And because it doesn't special case
> parser initiated mutations,
> those mutations should be there.
>
>
>> That is, that MutationObservers are not specified to be notified
>> of actions taken by the parser.
>
> That would be still very odd. The randomness that there is, is visible to
> scripts already now.
> You can't know the size of network packages, so you can't know exactly now
> documents are parsed etc.
>
> It would be also odd for scripts which use mutation observer to start
> working suddenly when
> document enters into some state (readyState == "complete" or some such).
> During page load user initiated events could cause all sorts of mutations
> but there wasn't a way to get notified
> about those.

Like Olli says, the randomness is already there. It's inherent with
loading content from the network. Not firing MutationObservers doesn't
reduce randomness at all, it just makes it harder to deal with since
you need to use polling rather than getting observer callbacks. So if
the concern is that there is randomness involved with parsing, we are
just doing a disservice by disabling MutationObserver callbacks.

I think it would significantly reduce the reliability of the API if we
don't notify about parser mutations. It basically means that
MutationObservers are completely unreliable until DOMContentLoaded has
fired for a document. In fact, it would likely be more understandable
to say that no MutationObserver callbacks happen before
DOMContentLoaded has fired, rather than making the distinction between
parser mutation and non-parser mutations.

Actually, the situation is even worse since even after
DOMContentLoaded has fired, parser mutations can still occur. If a
page opens an  and moves nodes out of it while parsing is
still happening, it can result in that the s parser making
changes to the parent document, which wouldn't then notify
MutationObservers.

All in all I think that as soon as we introduce exceptions to when
MutationObserver callbacks fire we change the API from being a
reliable way to track DOM mutations to a unreliable way where all
callers have to be aware of exceptions and deal with them in other
ways. I.e. it feels like it significantly reduces the value of
MutationObservers.

And so far I don't see any good arguments made for making that
reduction in value. Did I miss any arguments other then the randomness
argument?

/ Jonas

[Bug 17644] OK I spent hours all over the web and your docs getting to grips with websocket, my question now is this.... in the the handshake....how does one actually implement the header for the we

2012-06-29 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17644

Olli Pettay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b...@pettay.fi
 Resolution||INVALID

--- Comment #1 from Olli Pettay  2012-06-29 08:04:18 UTC ---
Protocol is defined in the IETF spec.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.