date:20111003

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14351

Anne ann...@opera.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne ann...@opera.com 2011-10-03 09:33:17 UTC ---
Bah.

http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/xhr-source.diff?r1=1.119;r2=1.120;f=h

-- 
Configure bugmail: http://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: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-10-03 Thread Brian Kardell

Is x-mywidget necessarily more performant?  Why?

On Oct 3, 2011 5:33 AM, Roland Steiner rolandstei...@google.com wrote:

 If I may briefly summarize the pros and cons of every approach discussed:

 X-MYWIDGET

 Pros:
 - element name is inherently immutable
 - can provide arbitrary API, can (but does not have to) derive from
arbitrary HTML element
 - best performance (in instantiation, CSS selector matching)
 Cons:
 - accessibility only for shadow tree contents, no accessibility for host
element unless ARIA roles are specified
 - parsing issues in special circumstances (table, auto-closing p,
etc.)
 - no/limited fallback (limited: user provides fallback as content of
X-MYWIDGET, won't work in special places like within tables)
 - makes it easy to conflate semantics and representation

 button IS=MYWIDGET

 Pros:
 - fallback behavior as per HTML element
 - accessibility as per HTML element + shadow tree contents
 - binding only at creation, or immediately thereafter
 - API is that of host element, +alpha
 Cons:
 - add'l APIs ignored for accessibility
 - harder to implement: there's a window during parsing (before reading the
button) where it's still an ordinary button, requiring binding to be added
afterwards
 - immutability of 'is' attribute not immediately obvious to authors
 - unclear what happens if a HTML element with intrinsic shadow DOM is
assigned a CSS binding

 button { BINDING: MYWIDGET; }

 Pros:
 - fallback behavior as if un-styled
 - accessibility
 - mutability depending on medium, etc.
 - host element stays unchanged
 Cons:
 - dynamic binding is hard to implement
 - shadow DOM dependent on rendering tree (something we explicitly wanted
to avoid)
 - API immutable that of host element
 - unclear what happens if a HTML element with (intrinsic or explicit)
shadow DOM is assigned a CSS binding as well


 Does the above look about right?

 - Roland

Re: HTML element content models vs. components

2011-10-03 Thread Alex Russell

What Charles said = )

On Wed, Sep 28, 2011 at 5:22 PM, Charles Pritchard ch...@jumis.com wrote:

On 9/27/2011 11:39 PM, Roland Steiner wrote:

Expanding on the general web component discussion, one area that hasn't
been touched on AFAIK is how components fit within the content model of HTML
elements.
Take for example a list (http://www.whatwg.org/specs/**
web-apps/current-work/**multipage/grouping-content.**html#the-ul-elementhttp://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-ul-element):

ol and ul have Zero or more li elements as content model, while
li is specified to only be usable within ol, ul and menu.

Now it is not inconceivable that someone would like to create a component
x-li that acts as a list item, but expands on it. In order to allow this,
the content model for ol, ul, menu would need to be changed to
accomodate this. I can see this happening in a few ways:

A.) allow elements derived from a certain element to always take their
place within element content models.

In this case, only components whose host element is derived from li
would be allowed within ol, ul, menu, whether or not it is rendered
(q.v. the Should the shadow host element be rendered? thread on this ML).

B.) allow all components within all elements.

While quite broad, this may be necessary in case the host element isn't
rendered and perhaps derivation isn't used. Presumably the shadow DOM in
this case contains one - or even several - li elements as topmost elements
in the tree.

C.) Just don't allow components to be used in places that have a special
content model.

Thoughts?

Consider the CSS content model: we can easily override the model of various
tags.
Then consider ARIA role types, where we can easily override the semantics
of various tags.

I'm a big fan of using appropriate tag names, but I'm not convinced that
HTML should restrict CSS or ARIA.
The HTML5 editor has repeatedly tried to enforce option C, restricting
components in the DOM tree in relation to ARIA and HTML Canvas.

Why bother over-specifying? Why remove that flexibility?

HTML tag names are fantastic, I'm not saying lets just toss HTML, but I
don't think HTML is the top of the hierarchy.
We have ARIA for semantics, CSS for display and DOM for serialization.

-Charles

Re: [XHR2] responseText for text/html before the encoding has stabilized

2011-10-03 Thread Henri Sivonen

On Fri, Sep 30, 2011 at 8:05 PM, Jonas Sicking jo...@sicking.cc wrote:
 Unless responseType== or responseType==document I don't think we
 should do *any* HTML or XML parsing. Even the minimal amount needed to
 do charset detection.

I'd be happy to implement it that way.

 For responseType==text we currently *only* look at http headers and
 if nothing is found we fall back to using UTF8. Though arguably we
 should also check for a BOM, but don't currently.

Not checking for the BOM looks like a bug to me though not a
particularly serious one given that the default is UTF-8, so the
benefit of checking the BOM is that people can use UTF-16. But using
UTF-16 on the wire is a bad idea anyway.

This could be fixed for consistency without too much hardship but it's
rather useless use of developer time.

On Fri, Sep 30, 2011 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
 So... the prescanning is generally considered optional

I consider that a spec bug. For the sake of well-defined behavior, I
think the spec should require buffering up to 1024 bytes in order to
look for a charset meta without a timeout (but buffering should stop
as soon as a charset meta has been seen, so that if the meta
appears early, there's no useless stalling until the 1024-byte
boundary).

 (the only benefit
 really is that it avoids reloads in bad cases), and indeed implementations
 are somewhat encouraged to abort it early if the server only sent a few
 bytes (because that will shorten the time until something is displayed).

Firefox has buffered up to 1024 bytes without a timeout since Firefox
4. I have received no reports of scripts locking due to the buffering.
There have been a couple of reports of incremental display of progress
messages having become non-incremental, but those were non-fatal and
easy to fix (by declaring the encoding).

 Also, it has a number of false-positives, e.g. it doesn't ignore the
 contents of script elements.

I think restarts with scripts are much worse than mostly-theoretical
false positives. (If someone puts a charset meta inside a script,
they are doing it very wrong.)

 Do we really want to put it into the critical path in this way?

For responseType ==  and responseType == document, I think doing
so would be less surprising than ignoring meta. For responseType ==
text and responseType == chunked-text or any response type that
doesn't actually involve running the full HTML parser, I'd rather not
run the meta prescan, either.

 I agree that the reloading alternative is even worse.

Yes.

 What about just
 relying on the Content-Type charset= and defaulting to UTF-8 if it isn't
 there, and not doing any in-page stuff?

That would be easy to implement, but it would be strange not to
support some ways of declaring the encoding that are considered
conforming by HTML.

 How is the encoding determined for, e.g., text/plain or text/css files
 brought down through XHR and viewed through responseText?

Per spec, @charset isn't honored for text/css, so in that sense, not
honoring meta would be consistent. However, I'd be hesitant to stop
honoring the XML declaration for XML, since the could well be content
depending on it. XML and CSS probably won't end up being treated
consistently with each other. But then, XHR doesn't support parsing
into a CSS OM.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

[Bug 14364] New: [appcache] manifest attribute should accept data-uris

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364

   Summary: [appcache] manifest attribute should accept data-uris
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: louisr...@mozilla.com
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


A simple way to make the appcache dynamic would be to allow data-uris as
manifests, to allow scripts to require new ressources to be cached, without
server round-trips.

This is of course not an ideal solution to make the appcache dynamic, but it is
one easy to implement and to get out of the door quickly.

-- 
Configure bugmail: http://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 14288] document.documentElement.insertAdjacentHTML specs WebKit behavior instead of IE behavior

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14288

Ms2ger ms2...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 OS/Version|Linux   |All

--- Comment #5 from Ms2ger ms2...@gmail.com 2011-10-03 15:33:51 UTC ---
I am told that

  document.documentElement.insertAdjacentHTML(beforebegin, div/div)

adds a second element child to the document in IE8 and IE9, and throws (per
spec) in IE10, and that it throws in the null-parent case as well. That is, IE
appears to match Gecko.

After discussion with Henri, I went with throwing in both cases.

https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/ee0ba6d66250

-- 
Configure bugmail: http://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 14331] Hello! Why tasks that are queued by EventSource doesnot removed from task queues with close method? Thanks!

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NEEDSINFO   |

--- Comment #4 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-03 16:08:48 UTC 
---
I guess we can clear them, but that just means we're discarding  events that
were received before the close() method was called (even though they're being
fired after).

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

IndexedDB: ordering sense of IDBFactory.cmp?

2011-10-03 Thread Joshua Bell

As we're implementing IDBFactory.cmp in WebKit we noticed that the
ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/=
operators, etc.

As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first
 second

C's memcmp/strcmp(first, second) return -1 if first  second
Perl's (first cmp second) and (first = second) operators return -1
if first  second
Java's first.compareTo(second) returns  0 if first  second
.NET's String.Compare(first, second) returns  0 if first  second

We're wondering if this will be a usability issue with the API, if there's
a good justification for this seemingly inverted ordering, and if it's not
too late to reverse this in the spec.

Re: IndexedDB: ordering sense of IDBFactory.cmp?

On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell jsb...@chromium.org wrote:
 As we're implementing IDBFactory.cmp in WebKit we noticed that the
 ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/=
 operators, etc.
 As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first
  second
 C's memcmp/strcmp(first, second) return -1 if first  second
 Perl's (first cmp second) and (first = second) operators return -1
 if first  second
 Java's first.compareTo(second) returns  0 if first  second
 .NET's String.Compare(first, second) returns  0 if first  second
 We're wondering if this will be a usability issue with the API, if there's
 a good justification for this seemingly inverted ordering, and if it's not
 too late to reverse this in the spec.

I don't recall any particular reason for the current order. I suspect
it was simply a mistake.

I'm all for reversing order.

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed


On 9/30/11 9:46 PM, Adrian Bateman wrote:

Hi Arun,

Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB, we're
happy with the new WebIDL approach.

I think we should go ahead and migrate the File API exceptions to this new
model and use ISSUE-182 to drive that change.


Adrian,

That's great :)  Just to clarify from a File API perspective, are you ok 
with an OperationNotAllowed exception, *or* are you advocating reuse of 
DOMException with OperationNotAllowed like how IndexedDB is doing?  I'm 
unclear whether I should change what is in the editor's draft now.


A somewhat affiliated question is whether there should be a message 
attribute in our FileException and OperationNotAllowed exceptions (and 
in FileError).


-- A*

RE: [indexeddb] New WebIDL Exception Model for IndexedDB

On Sat, 1 Oct 2011, Israel Hilerio wrote:
 
 We believe it is simpler and closer to the intent on the WebIDL spec to 
 say: Throws a DOMException of type  VersionError.
 
 Instead of having to explain what it means to throw a type as an 
 exception: To throw a “VersionError” exception, a user agent would 
 construct a DOMException exception whose type is  VersionError  and 
 code exception field value is 0, and actually throw that object as an 
 exception.

If you use WebIDL directly, don't forget to specify the value for the 
'code' and 'message' attributes of the exception object.

(The reason I made the HTML spec use the DOM Core definition here is that 
it takes care of all the various features of DOMException so I don't have 
to worry about them at all.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors


On 9/30/11 11:14 AM, Anne van Kesteren wrote:

On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:

I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's explained XHR2's model, it seems that an open can
cancel the loadend that an abort would have sent.  So the invariants
need to be a bit more complex.


Well lets not accept as XHR2 as set-in-stone.

We could also change XHR2 to not cancel abort() when invoking open(). 
Then you get scenarios such as:


  abort()
  - abort event that invokes open()
 - readystatechange event
  - loadend event
  - abort event on XHRUpload
  - loadend event on XHRUpload

Instead of everything after the readystatechange event not happening. 
We could also introduce a flag and make it impossible to call open() 
from an event handler.


Maybe the simplest is the above. You can call open() from event 
handlers, but events will still be dispatched (and readyState will 
have changed). This is somewhat ugly, but then you should probably not 
invoke open() from event handlers anyway.



This gives us the desirable invariant that a loadstart will always have 
a loadend, which I think simplifies this model.  It seems useful to 
proceed with this in FileAPI.


-- A*

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan a...@mozilla.com wrote:
 On 9/30/11 9:46 PM, Adrian Bateman wrote:

 Hi Arun,

 Thanks for the follow-up - you beat me to it. We've been reviewing this in
 the context of the other specs and, as Israel outlined for IndexedDB,
 we're
 happy with the new WebIDL approach.

 I think we should go ahead and migrate the File API exceptions to this new
 model and use ISSUE-182 to drive that change.

 Adrian,

 That's great :)  Just to clarify from a File API perspective, are you ok
 with an OperationNotAllowed exception, *or* are you advocating reuse of
 DOMException with OperationNotAllowed like how IndexedDB is doing?  I'm
 unclear whether I should change what is in the editor's draft now.

 A somewhat affiliated question is whether there should be a message
 attribute in our FileException and OperationNotAllowed exceptions (and in
 FileError).

Here are my feelings:

1. Get rid of FileError/OperationNotAllowedException completely. All
exceptions we throw should be DOMExceptions.
2. We should try to reuse as many exceptions as we can from the DOM4 spec.

That means that in the places where we throw
OperationNotAllowedException we should throw a DOMException with
.name=InvalidStateError.

For SECURITY_ERR we'll want to use DOMException with .name=SecurityError

For ABORT_ERR we'll want to use DOMException with .name=AbortError

For NOT_READABLE_ERR I think we'll want to mint a new error. Something
like DOMException with .name=IOError or some such?

For ENCODING_ERR, I think we'll want to mint a new error. DOMException
with .name=CharsetEncodingError maybe?

In the cases where we reuse existing errors, the .code should be set
to the code that the DOM4 spec defines. But I think if we use the
correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne
who helped out with this for IndexedDB recently.

/ Jonas

Re: Generic guide to exceptions, events, etc. for new APIs Re: [indexeddb] New WebIDL Exception Model for IndexedDB


On 10/2/11 7:38 AM, Marcos Caceres wrote:



On Saturday, 1 October 2011 at 08:15, Anne van Kesteren wrote:


On Sat, 01 Oct 2011 02:56:55 +0200, Israel Hilerioisra...@microsoft.com 
(mailto:isra...@microsoft.com)
wrote:

On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:

Actually, given
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
it does. Which is what I was trying to convey. HTML does this too now:
http://html5.org/r/6602


The DOM 4 spec link you sent us is exactly the approach we’re following
but with a simpler language. Instead of defining what it means to throw
a type as an exception (like you do on DOM 4), we’re following the
WebIDL spec to define the exception type in a simpler fashion. Look at
the note contained in the WebIDL spec under IDL Exceptions where it says
there is no IDL syntax for declaring exception types:
http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions

We believe it is simpler and closer to the intent on the WebIDL spec to
say: Throws a DOMException of type  VersionError.


It's also wrong, since it does not say what code will be.



Instead of having to explain what it means to throw a type as an
exception:
To throw a “VersionError” exception, a user agent would construct a
DOMException exception whose type is  VersionError  and code exception
field value is 0, and actually throw that object as an exception.


It seems you misunderstood DOM4. All you need to say is:

# Throw a VersionError exception

That is it. The DOM4 definition of throw handles the details, such as
setting message and code.

This is great! Makes it super easy.




This discussion shows that the review process can catch these types of
issues and reviewers like yourself can make us aware of exceptions we
should reuse. Even if it didn’t, the worst case scenario is that a
developer would have similar Exceptions that have slightly different
types and names. Each name or type should be meaningful enough for the
developer to allow them to disambiguate. The main point is that we
don’t believe we should over engineer a solution to a problem that is
not pervasive at this point.

We could even add a note to the DOM 4 spec that states, We encourage
the reuse of these exceptions instead of defining new ones. Only define
new ones if the current set of exceptions doesn’t meet your needs.


I guess I don't really see what you think the problem is with keeping a
non-normative table in DOM4 (or elsewhere) listing the exceptions in use.


(generally speaking...)
Seems there is a lot of confusion about how to do this properly (and I'm seeing 
that this is going to now be an issue amongst a number of groups, including 
this group, DAP, and even other organisations that are trying their best to 
define new APIs such as Webinos and WAC).

Perhaps the best thing to do would be to create a wiki page that defines how to do this 
using some very generic examples. What would be great would be to see how the prose maps 
to the IDL and how the IDL maps to a real object in Java script… and also show how the 
DOM4 spec takes care of setting the code and the message…. so, a Exceptions and 
events for [Spec Writing] Dummies would be greatly appreciated (and will avoid a 
few common mistakes).


I agree, and admit to confusion on my part here as well.  I'm keen that 
errors and exceptions are spec'd consistently across the platform.  
We're now contemplating eliminating things that we once took for granted 
(for example, having a dedicated exception such as FileException, etc.).


-- A*

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote:
 On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:

 I think that works; #2 will be especially important.
 However, if I read this right, we *don't* have the invariant that a
 loadstart will always have a loadend.
 Now that Anne's explained XHR2's model, it seems that an open can
 cancel the loadend that an abort would have sent.  So the invariants
 need to be a bit more complex.

 Well lets not accept as XHR2 as set-in-stone.

 We could also change XHR2 to not cancel abort() when invoking open(). Then
 you get scenarios such as:

  abort()
  - abort event that invokes open()
     - readystatechange event
  - loadend event
  - abort event on XHRUpload
  - loadend event on XHRUpload

 Instead of everything after the readystatechange event not happening. We
 could also introduce a flag and make it impossible to call open() from an
 event handler.

 Maybe the simplest is the above. You can call open() from event handlers,
 but events will still be dispatched (and readyState will have changed). This
 is somewhat ugly, but then you should probably not invoke open() from event
 handlers anyway.

Unfortunately I suspect wanting to call open from event handlers is a
pretty common use case. Here are two use cases:

1. In case of a network error, let the onerror handler retry the request.
2. Implementing a auto-complete UI backed by data stored on the
server. Any time the user hits another character, abort the current
request and perform a new request with the newly typed value.

In the first case it makes sense to call .open/.send from the onerror
handler. In the second case it makes sense to do so from the onabort
handler.

I'm personally split on the issue. On one hand I really like the
simplicity of saying that each loadstart is always paired with a
loadend. On the other hand, I have a hard time thinking of any use
cases which *wouldn't* be helped by simply dropping the loadend
event if a new load had been started.

For example if you're implementing a progress bar, it would be very
easy to make the mistake of hiding the progress bar from loadend and
showing it in loadstart. In the two use cases above, that would
result in the progress bar not showing during the second load. I'll
leave as an exercise to the reader how to avoid such a bug ;-)

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed


On 10/3/11 4:59 PM, Jonas Sicking wrote:

On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com  wrote:

On 9/30/11 9:46 PM, Adrian Bateman wrote:

Hi Arun,

Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB,
we're
happy with the new WebIDL approach.

I think we should go ahead and migrate the File API exceptions to this new
model and use ISSUE-182 to drive that change.

Adrian,

That's great :)  Just to clarify from a File API perspective, are you ok
with an OperationNotAllowed exception, *or* are you advocating reuse of
DOMException with OperationNotAllowed like how IndexedDB is doing?  I'm
unclear whether I should change what is in the editor's draft now.

A somewhat affiliated question is whether there should be a message
attribute in our FileException and OperationNotAllowed exceptions (and in
FileError).

Here are my feelings:

1. Get rid of FileError/OperationNotAllowedException completely. All
exceptions we throw should be DOMExceptions.
2. We should try to reuse as many exceptions as we can from the DOM4 spec.


Eeep!  :)  This is a big-ish change, but I'm amenable to it, especially 
to stay consistent with what IndexedDB is doing (and to be consistent 
with HTML/XHR2, etc.).  But to be clear, above you mean:


1. Get rid of FileException and OperationNotAllowedException completely, 
but you probably do NOT mean get rid of FileError.  We'll want to keep 
FileError since it's an asynchronously handled error object in onerror, 
but we'll reuse whatever we reuse from DOMException, if it makes sense 
to do so.


Honestly, implementations are not consistent with respect to what they 
throw today with respect to FileException and read-affiliated 
exceptions, so if it helps get us some consistency by channeling things 
through DOM4 (and WebIDL), I'm okay with it, short term pain of changing 
the spec. notwithstanding.


That means that in the places where we throw
OperationNotAllowedException we should throw a DOMException with
.name=InvalidStateError.


OK.


For SECURITY_ERR we'll want to use DOMException with .name=SecurityError


OK.


For ABORT_ERR we'll want to use DOMException with .name=AbortError


We don't actually throw an ABORT_ERR, so one thing that's attractive 
about making this change is that we'll eliminate redundant codes in 
objects we don't actually use.




For NOT_READABLE_ERR I think we'll want to mint a new error. Something
like DOMException with .name=IOError or some such?


OK.  So it's when we need new exception codes, names, and types that the 
confusion with this model sets in.  While we can add to DOMException in 
a decentralized way, do the editors of DOM4 intend to add the new 
exceptions to DOMException?



For ENCODING_ERR, I think we'll want to mint a new error. DOMException
with .name=CharsetEncodingError maybe?


OK (same question).


In the cases where we reuse existing errors, the .code should be set
to the code that the DOM4 spec defines. But I think if we use the
correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne
who helped out with this for IndexedDB recently.


(Commentary from Anne welcome).

-- A*

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

2011-10-03 Thread Glenn Maynard

On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:

 Unfortunately I suspect wanting to call open from event handlers is a
 pretty common use case. Here are two use cases:

 1. In case of a network error, let the onerror handler retry the request.

2. Implementing a auto-complete UI backed by data stored on the
 server. Any time the user hits another character, abort the current
 request and perform a new request with the newly typed value.


These can be handled trivially by wrapping in a timer.  This is a basic
platform concept, an approximation of queue a task so common in specs.

(#2 isn't actually a problem, since it's an event from a different
source--it's only recursing back into the same XHR/FileReader/etc. object
from its own events that causes ugliness.)

For example if you're implementing a progress bar, it would be very
 easy to make the mistake of hiding the progress bar from loadend and
 showing it in loadstart. In the two use cases above, that would
 result in the progress bar not showing during the second load. I'll
 leave as an exercise to the reader how to avoid such a bug ;-)


This shouldn't be a mistake--it's the natural, obvious way to use these
events.  You shouldn't have to worry about receiving two loadstarts in a
row, or two loadends in a row, or missing loadends, depending on what object
is firing the event, how its API is being used, or where your event listener
is in the event handler list.

Needing to use setTimeout in some cases is a tiny price to pay, to avoid
having to worry about that mess and keep these events straightforward and
predictable.

-- 
Glenn Maynard

Re: [File API] Issue 182 about OperationNotAllowed


On 10/3/11 6:59 PM, Jonas Sicking wrote:

On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathana...@mozilla.com  wrote:

On 10/3/11 4:59 PM, Jonas Sicking wrote:

On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com
  wrote:

On 9/30/11 9:46 PM, Adrian Bateman wrote:

Hi Arun,

Thanks for the follow-up - you beat me to it. We've been reviewing this
in
the context of the other specs and, as Israel outlined for IndexedDB,
we're
happy with the new WebIDL approach.

I think we should go ahead and migrate the File API exceptions to this
new
model and use ISSUE-182 to drive that change.

Adrian,

That's great :)  Just to clarify from a File API perspective, are you ok
with an OperationNotAllowed exception, *or* are you advocating reuse of
DOMException with OperationNotAllowed like how IndexedDB is doing?  I'm
unclear whether I should change what is in the editor's draft now.

A somewhat affiliated question is whether there should be a message
attribute in our FileException and OperationNotAllowed exceptions (and in
FileError).

Here are my feelings:

1. Get rid of FileError/OperationNotAllowedException completely. All
exceptions we throw should be DOMExceptions.
2. We should try to reuse as many exceptions as we can from the DOM4 spec.

Eeep!  :)  This is a big-ish change, but I'm amenable to it, especially to
stay consistent with what IndexedDB is doing (and to be consistent with
HTML/XHR2, etc.).  But to be clear, above you mean:

1. Get rid of FileException and OperationNotAllowedException completely, but
you probably do NOT mean get rid of FileError.  We'll want to keep FileError
since it's an asynchronously handled error object in onerror, but we'll
reuse whatever we reuse from DOMException, if it makes sense to do so.

Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.


I'm happy with a DOMError class that can be reused, but I'd rather not 
block on it unless it can be done in short order.  It might live in 
HTML, although currently the onerror handler for script errors (if a 
Function) has three arguments and doesn't seem to need a dedicated error 
object.


Earlier, when I wanted to keep constants in sync with DOMException, 
there was some resistance.  If we maintain a FileError object, it may 
now actually make sense to replicate some of the constants from 
DOMException, since there is no longer a FileException.  Or, we can 
follow how HTML handles script errors (and forego a dedicated error object).


Cc'ing Hixie as well to comment on what HTML might need.



OK.  So it's when we need new exception codes, names, and types that the
confusion with this model sets in.  While we can add to DOMException in a
decentralized way, do the editors of DOM4 intend to add the new exceptions
to DOMException?

I'll leave this one for Anne. I personally don't care where the new
strings are defined. Anne seemed to prefer to do it in the DOM4 (aka
DOM Core) spec, but I don't think we want to block on that happening.


I don't think we should block on DOM4 either.

-- A*

[indexeddb] Exception type for NON_TRANSIENT_ERR code

2011-10-03 Thread Israel Hilerio

On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
 For several of these I think we can reuse existing DOMExceptions.
 Here's how I'd map the exceptions which are currently in the IndexedDB
 spec:
 
 UNKNOWN_ERR
 Mint a new UnknownError. Alternatively we could simply throw an
 ECMAScript Error object with no more specific type.
 
 NON_TRANSIENT_ERR
 I think in many cases we should simply throw a TypeError here. That seems
 to match closely to how TypeError is used by WebIDL now.

As I'm mapping the Exception codes to the new Exception type model, I thought 
we should mint a new type for NON_TRANSIENT_ERR, NonTransientError.  The reason 
is that TypeError seems to be designed to cover all intrinsic conversion cases 
and NON_TRANSIENT_ERR seems to be dealing with additional validation beyond 
what TypeError normally checks for.  This will also allow us to assign a code 
value of 0 and a message: This error occurred because an operation was not 
allowed on an object. A retry of the same operation would fail unless the cause 
of the error is corrected.

What do you think?

Israel

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, 3 Oct 2011, Arun Ranganathan wrote:
 
 Cc'ing Hixie as well to comment on what HTML might need.

As far as I'm concerned, what HTML has now is fine (DOMException based 
on how DOM Core defines it).


  I'll leave this one for Anne. I personally don't care where the new 
  strings are defined. Anne seemed to prefer to do it in the DOM4 (aka 
  DOM Core) spec, but I don't think we want to block on that happening.
 
 I don't think we should block on DOM4 either.

Isn't it already done? It's what HTML is using...

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Bug 14323] This API could easily be used by XForms implementations if protocols such as localstorage:// could also be specified. Thanks! Alain Couthures agenceXML Invited Expert in Forms Work Gro

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14323

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NEEDSINFO

--- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-03 23:44:20 UTC 
---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 1

-- 
Configure bugmail: http://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: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard gl...@zewt.org wrote:
 On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:

 Unfortunately I suspect wanting to call open from event handlers is a
 pretty common use case. Here are two use cases:

 1. In case of a network error, let the onerror handler retry the request.

 2. Implementing a auto-complete UI backed by data stored on the
 server. Any time the user hits another character, abort the current
 request and perform a new request with the newly typed value.

 These can be handled trivially by wrapping in a timer.  This is a basic
 platform concept, an approximation of queue a task so common in specs.

 (#2 isn't actually a problem, since it's an event from a different
 source--it's only recursing back into the same XHR/FileReader/etc. object
 from its own events that causes ugliness.)

 For example if you're implementing a progress bar, it would be very
 easy to make the mistake of hiding the progress bar from loadend and
 showing it in loadstart. In the two use cases above, that would
 result in the progress bar not showing during the second load. I'll
 leave as an exercise to the reader how to avoid such a bug ;-)

 This shouldn't be a mistake--it's the natural, obvious way to use these
 events.  You shouldn't have to worry about receiving two loadstarts in a
 row, or two loadends in a row, or missing loadends, depending on what object
 is firing the event, how its API is being used, or where your event listener
 is in the event handler list.

Exactly!

 Needing to use setTimeout in some cases is a tiny price to pay, to avoid
 having to worry about that mess and keep these events straightforward and
 predictable.

Except that we can't do that for XHR since there's already tons of
content out there. Most likely enough of that content starts a new
load from onabort/onload/onerror that we can't make that throw. Which
leaves us with the following options:

1. Make loadend not fire in case a new load is started from
onabort/onload/onerror. Thus loadend and loadstart isn't always
paired up. Though there is always a loadend fired after every
loadstart.
2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also
leaves the problem unsolved for XHR.

Are there other options I'm missing?

/ Jonas

[indexeddb] Change IDBRequest.errorCode property to match new Exception type model

2011-10-03 Thread Israel Hilerio

Jonas,

We're removing error code values as part of the new exception type model.  This 
will impact the IDBRequest.errorCode property.  I believe we want to rename 
this property to errorName and change its type to DOMString in order to match 
the new Exception type model name. This change will impact all the places where 
errorCode is used today in the spec.  However, it should be fairly easy to fix 
assuming we follow the above model.

Do you agree?

Israel

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, Oct 3, 2011 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
 On Mon, 3 Oct 2011, Arun Ranganathan wrote:

 Cc'ing Hixie as well to comment on what HTML might need.

 As far as I'm concerned, what HTML has now is fine (DOMException based
 on how DOM Core defines it).


  I'll leave this one for Anne. I personally don't care where the new
  strings are defined. Anne seemed to prefer to do it in the DOM4 (aka
  DOM Core) spec, but I don't think we want to block on that happening.

 I don't think we should block on DOM4 either.

 Isn't it already done? It's what HTML is using...

I looked at how for example WebSockets and EventSource exposes error
information. I would have thought in both cases that it would have
been done as a property on the websocket/eventsource object itself.
However I couldn't find any such property, and since the error
events fired by both specifications are simple Events it doesn't
appear as if the information is exposed on the event object either.

Do neither of these specifications make error information available?

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan a...@mozilla.com wrote:
 On 10/3/11 4:59 PM, Jonas Sicking wrote:

 On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com
  wrote:

 On 9/30/11 9:46 PM, Adrian Bateman wrote:

 Hi Arun,

 Thanks for the follow-up - you beat me to it. We've been reviewing this
 in
 the context of the other specs and, as Israel outlined for IndexedDB,
 we're
 happy with the new WebIDL approach.

 I think we should go ahead and migrate the File API exceptions to this
 new
 model and use ISSUE-182 to drive that change.

 Adrian,

 That's great :)  Just to clarify from a File API perspective, are you ok
 with an OperationNotAllowed exception, *or* are you advocating reuse of
 DOMException with OperationNotAllowed like how IndexedDB is doing?  I'm
 unclear whether I should change what is in the editor's draft now.

 A somewhat affiliated question is whether there should be a message
 attribute in our FileException and OperationNotAllowed exceptions (and in
 FileError).

 Here are my feelings:

 1. Get rid of FileError/OperationNotAllowedException completely. All
 exceptions we throw should be DOMExceptions.
 2. We should try to reuse as many exceptions as we can from the DOM4 spec.

 Eeep!  :)  This is a big-ish change, but I'm amenable to it, especially to
 stay consistent with what IndexedDB is doing (and to be consistent with
 HTML/XHR2, etc.).  But to be clear, above you mean:

 1. Get rid of FileException and OperationNotAllowedException completely, but
 you probably do NOT mean get rid of FileError.  We'll want to keep FileError
 since it's an asynchronously handled error object in onerror, but we'll
 reuse whatever we reuse from DOMException, if it makes sense to do so.

Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.

 For NOT_READABLE_ERR I think we'll want to mint a new error. Something
 like DOMException with .name=IOError or some such?

 OK.  So it's when we need new exception codes, names, and types that the
 confusion with this model sets in.  While we can add to DOMException in a
 decentralized way, do the editors of DOM4 intend to add the new exceptions
 to DOMException?

I'll leave this one for Anne. I personally don't care where the new
strings are defined. Anne seemed to prefer to do it in the DOM4 (aka
DOM Core) spec, but I don't think we want to block on that happening.

/ Jonas

Re: [indexeddb] Exception type for NON_TRANSIENT_ERR code

On Mon, Oct 3, 2011 at 5:10 PM, Joshua Bell jsb...@chromium.org wrote:
 On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio isra...@microsoft.com
 wrote:

 On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
  NON_TRANSIENT_ERR
  I think in many cases we should simply throw a TypeError here. That
  seems
  to match closely to how TypeError is used by WebIDL now.

 As I'm mapping the Exception codes to the new Exception type model, I
 thought we should mint a new type for NON_TRANSIENT_ERR, NonTransientError.
  The reason is that TypeError seems to be designed to cover all intrinsic
 conversion cases and NON_TRANSIENT_ERR seems to be dealing with additional
 validation beyond what TypeError normally checks for.

 As an aside, the current draft has IDBFactory.cmp() raise a
 NON_TRANSIENT_ERR when an invalid key is used, but most of the other
 functions that take keys  (IDBObjectStore.add/put/get/delete(), etc) raise a
 DATA_ERR on invalid keys. It would be nice to be consistent in the case
 where the explicitly specified key is invalid (vs. when it is a calculated
 key).

Agreed. DataError seems like a better exception here.

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, 3 Oct 2011, Jonas Sicking wrote:
 
 I looked at how for example WebSockets and EventSource exposes error 
 information. I would have thought in both cases that it would have been 
 done as a property on the websocket/eventsource object itself. However I 
 couldn't find any such property, and since the error events fired by 
 both specifications are simple Events it doesn't appear as if the 
 information is exposed on the event object either.
 
 Do neither of these specifications make error information available?

Web Sockets exposes error information in the 'close' handler, if that 
counts. That's unrelated to exceptions, though. It uses a custom event 
interface type.

Generally speaking I try to avoid exposing too much error information to 
script (as opposed to the developer console) because it can often lead to 
security problems (e.g. leaking information about intranet topology).

HTMLMediaElement exposes error state on a .error attribute that returns a 
MediaError object (or null), which itself just has a single .code 
attribute currently, that being a value from 1 to 4 (corresponding to some 
defined constants). At some point in the future it may be extended to 
provide more information in the object, but there are no immediate plans 
to do so. In any case, this is also not an exception, and no attempt is 
made to keep these codes synced with the exception codes.

All exception handling in the HTML spec uses the DOM Core behaviour.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
 On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:

 1. Make loadend not fire in case a new load is started from
 onabort/onload/onerror. Thus loadend and loadstart isn't always
 paired up. Though there is always a loadend fired after every
 loadstart.
 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also

 leaves the problem unsolved for XHR.

 Are there other options I'm missing?

 Or do both, improving XHR as much as backwards-compatibility allows and
 don't try to match other APIs to it exactly.  I'd much prefer weirdness be
 isolated to XHR than be perpetuated through every PE-based API.

So what exactly are you proposing we do for XHR and for FileReader/FileWriter?

I'm still not convinced that it's better for authors to require them
to use setTimeout to start a new load as opposed to let them restart
the new load from within an event and cancel all following events. I
agree that this introduces some inconsistency, but it only does so
when authors explicitly reuses a FileReader/XHR/FileWriter for
multiple requests.

And it only weakens the invariant, not removes it. So instead of

* There's exactly one 'loadend' event for each 'loadstart' event.

we'll have

* There's always a 'loadend' event fired after each 'loadstart' event.
However there might be other 'loadstart' events fired in between.

/ Jonas

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson i...@hixie.ch wrote:
 On Mon, 3 Oct 2011, Jonas Sicking wrote:

 I looked at how for example WebSockets and EventSource exposes error
 information. I would have thought in both cases that it would have been
 done as a property on the websocket/eventsource object itself. However I
 couldn't find any such property, and since the error events fired by
 both specifications are simple Events it doesn't appear as if the
 information is exposed on the event object either.

 Do neither of these specifications make error information available?

 Web Sockets exposes error information in the 'close' handler, if that
 counts. That's unrelated to exceptions, though. It uses a custom event
 interface type.

 Generally speaking I try to avoid exposing too much error information to
 script (as opposed to the developer console) because it can often lead to
 security problems (e.g. leaking information about intranet topology).

 HTMLMediaElement exposes error state on a .error attribute that returns a
 MediaError object (or null), which itself just has a single .code
 attribute currently, that being a value from 1 to 4 (corresponding to some
 defined constants). At some point in the future it may be extended to
 provide more information in the object, but there are no immediate plans
 to do so. In any case, this is also not an exception, and no attempt is
 made to keep these codes synced with the exception codes.

 All exception handling in the HTML spec uses the DOM Core behaviour.

I agree that exposing error information can be a problem. However it
seems like this is safe enough in specs where we use CORS or similar
explicit-opt-in protocols. In those cases I think it's generally a
good idea to expose error info to pages.

So MediaError is exactly the type of thing that I'm talking about that
we might want to move into the DOM4 spec. We have the same thing in
the File API spec. The FileError interface is just a plain object with
a single .code property. We're planning on moving that to expose a
.name property instead which will contain the same strings as
DOMException.name.

I'm thinking we should do the same thing for IndexedDB too.

So having a central DOMError interface which we can reuse for all
places which expose asynchronous errors would be helpful. If
specifications want to add more information than what's defined by
DOM4, they can always extend the interface.

/ Jonas

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

2011-10-03 Thread Glenn Maynard

On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:

 So what exactly are you proposing we do for XHR and for
 FileReader/FileWriter?


For APIs other than XHR, don't allow calling read* or abort during events
fired on the object from its own algorithms.  This should give the guarantee
that loadstart and loadend will always be paired and non-interleaved, and
give developers a simple rule: if you need to start a new operation from
these events, push it into a timer (queue a task).

(More precisely, no method that starts or finishes a loadstart/loadend
sequence can be called from within an algorithm that also starts or finishes
a sequence.  abort() from within onprogress is fine, for example.)

I don't have a strong opinion about what to do with XHR--my main worry is
not perpetuating ugliness into every PE API in order to mimic XHR.

And it only weakens the invariant, not removes it. So instead of

 * There's exactly one 'loadend' event for each 'loadstart' event.

 we'll have

 * There's always a 'loadend' event fired after each 'loadstart' event.
 However there might be other 'loadstart' events fired in between.


When can this happen, with the above restriction in place (speaking of eg.
FileReader, not XHR)?

-- 
Glenn Maynard

Re: [indexeddb] Exception type for NON_TRANSIENT_ERR code

On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio isra...@microsoft.com wrote:
 On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
 For several of these I think we can reuse existing DOMExceptions.
 Here's how I'd map the exceptions which are currently in the IndexedDB
 spec:

 UNKNOWN_ERR
 Mint a new UnknownError. Alternatively we could simply throw an
 ECMAScript Error object with no more specific type.

 NON_TRANSIENT_ERR
 I think in many cases we should simply throw a TypeError here. That seems
 to match closely to how TypeError is used by WebIDL now.

 As I'm mapping the Exception codes to the new Exception type model, I thought 
 we should mint a new type for NON_TRANSIENT_ERR, NonTransientError.  The 
 reason is that TypeError seems to be designed to cover all intrinsic 
 conversion cases and NON_TRANSIENT_ERR seems to be dealing with additional 
 validation beyond what TypeError normally checks for.  This will also allow 
 us to assign a code value of 0 and a message: This error occurred because an 
 operation was not allowed on an object. A retry of the same operation would 
 fail unless the cause of the error is corrected.

The reason I'm not a fan of NonTransientError is that it doesn't
really mean anything. All it says is you'd get the same error if you
tried the operation again. However that is true for almost all
exceptions in any DOM spec. The only case that I can think of where
that isn't the case is when using the synchronous IndexedDB API or
when using synchronous XHR.send and there is a IO or network error.

I looked through the spec and came up with this list for when we're
currently throwing NON_TRANSIENT_ERR and I agree that not in all of
them it makes sense to use TypeError. Here is what I came up with:

IDBFactory.cmp if either key is not a valid key
  This should throw DataError per Joshua's email.

IDBDatabase(Sync).createObjectStore if the keypath argument contains
an invalid keypath
  This best fit here seems to be SyntaxError in DOMException.

IDBDatabase(Sync).createObjectStore if the options argument is handed
an object with properties other than those in the dictionary.
  This doesn't actually match how dictionaries are supposed to behave
per WebIDL. They are defined to ignore all properties not defined by
the dictionary IDL. So we should remove this exception and also change
the type of this argument to use IDBDatabaseOptionalParameters
rather than Object.

IDBDatabase(Sync).transaction when passed an invalid mode
  I think other specs throw a TypeError in similar situations, but
can't think of any examples off the top of my head.

IDBObjectStore(Sync).createIndex if the keypath argument contains an
invalid keypath
  Same as for createObjectStore

IDBObjectStore(Sync).createIndex if the options argument is handed an
object with properties other than those in the dictionary.
  Same as for createObjectStore

IDBCursor(Sync).advance if passed a negative or zero value
  WebIDL throws TypeError in other similar out-of-range situations

Let me know what you think.

/ Jonas

Re: [indexeddb] Change IDBRequest.errorCode property to match new Exception type model

On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio isra...@microsoft.com wrote:
 Jonas,

 We’re removing error code values as part of the new exception type model.
 This will impact the IDBRequest.errorCode property.  I believe we want to
 rename this property to errorName and change its type to DOMString in order
 to match the new Exception type model name. This change will impact all the
 places where errorCode is used today in the spec.  However, it should be
 fairly easy to fix assuming we follow the above model.

 Do you agree?

We might want to do something similar to what the FileAPI spec is
doing, and the HTML5 spec is doing for HTMLMediaElement. Both specs
have a .error property which returns an object which contains error
information. A nice aspect of that approach is that it enables us to
add more information about the error later, and even have different
pieces of information for different errors.

/ Jonas

Re: [File API] Issue 182 about OperationNotAllowed

On Mon, 3 Oct 2011, Jonas Sicking wrote:
 
 So MediaError is exactly the type of thing that I'm talking about that 
 we might want to move into the DOM4 spec. We have the same thing in the 
 File API spec. The FileError interface is just a plain object with a 
 single .code property. We're planning on moving that to expose a .name 
 property instead which will contain the same strings as 
 DOMException.name.
 
 I'm thinking we should do the same thing for IndexedDB too.
 
 So having a central DOMError interface which we can reuse for all places 
 which expose asynchronous errors would be helpful. If specifications 
 want to add more information than what's defined by DOM4, they can 
 always extend the interface.

Oh, I don't think I'd use a central error interface for 
HTMLMediaElement.error. I don't really see much value to it. Going forward 
I see us putting all kinds of media-specific stuff in there like the name 
of the codec, the frame at which the error occurred, or other such things. 
Those wouldn't make sense in a FileError equivalent. In a FileError I 
would imagine seeing such things as a reference to the relevant File 
object, or a byte offset into where the read error occurred, or whatnot.

We could have them all inherit from a common Error interface, but honestly 
that doesn't get us much.

I agree that we should try to be consistent going forward. It's not a huge 
issue though. I don't mind adding a name attribute to MediaError at some 
point if that's the way other such interfaces go. I don't expect most 
authors to ever interact with this part of the API so it's not a high 
priority. (First we have to add video metrics, for instance. In some 
manner that doesn't lead to helping fingerprinters...)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard gl...@zewt.org wrote:
 On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:

 So what exactly are you proposing we do for XHR and for
 FileReader/FileWriter?

 For APIs other than XHR, don't allow calling read* or abort during events
 fired on the object from its own algorithms.  This should give the guarantee
 that loadstart and loadend will always be paired and non-interleaved, and
 give developers a simple rule: if you need to start a new operation from
 these events, push it into a timer (queue a task).

 (More precisely, no method that starts or finishes a loadstart/loadend
 sequence can be called from within an algorithm that also starts or finishes
 a sequence.  abort() from within onprogress is fine, for example.)

I think this is a higher cost to developers than the cost of having
loadstart always be paired up with exactly one loadend.

Note that this would mean that you also couldn't start a new load from
within the loadend event since that would cause event listeners
after yours to receive interleaved loadstart/loadend events.

The main problem here is actually the fact that loadend is fired
synchronously from read*. If we removed that constraint then we could
allow loads to start from anywhere without having to worry about
interleaved loadstart/loadend.

But it's somewhat doubtful that we can make such a big change to
FileReader given that it's been in the wild for a while :(

/ Jonas

Re: [indexeddb] Implicit Transaction Request associated with failed transactions

On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio isra...@microsoft.com wrote:
 Based on previous conversations, it seems we've agreed that there are 
 situations in which a transaction could failed independent of explicit 
 requests (i.e. QUOTA_ERR, TIMEOUT_ERR).  We believe that this can be 
 represented as an implicit request that is being triggered by a transaction.  
 We would like to add this concept to the spec.  The benefit of doing this is 
 that it will allow developers to detect the error code associated with a 
 direct transaction failure.  This is how we see the concept being used:

 trans.onerror = function (e) {
 //eventTarget is mapped to an implicit transaction that was created behind 
 the scenes to track the transaction

  if (e.eventTarget.errorCode === TIMEOUT_ERR) {
    // you know the transaction error because of a timeout problem
  }
  else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
   // you know the transaction error because of a quota problem
  }
 }

 Our assumption is that the error came not from an explicit request but from 
 the transaction itself.  The way it is today, the e.eventTarget will not 
 exists (will be undefined) because the error was not generated from an 
 explicit request.  Today, eventTargets are only populated from explicit 
 requests.

Good catch!

We had a long thread about this a while back with the subject
[IndexedDB] Reason for aborting transactions. But it seems to have
fizzled with no real conclusion as to changing the spec. In part that
seems to have been my fault pushing back at exposing the reason for a
aborted transaction.

I think I was wrong :-)

I think I would prefer adding a .errorCode on IDBTransaction through
(or .errorName or .error or whatever we'll end up changing it to).
This seems more clear than creating a implicit request object. It'll
also make it easy to find the error if you're outside the error
handler. With the implicit request, you have no way of getting to the
request, and thus the error code, from code outside the error handler,
such from code that looks at the transaction after it has run.

And the code above would work exactly as is!

Let me know what you think?

/ Jonas

Re: [indexeddb] Exception type for NON_TRANSIENT_ERR code

On Mon, Oct 3, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote:
 IDBDatabase(Sync).createObjectStore if the options argument is handed
 an object with properties other than those in the dictionary.
  This doesn't actually match how dictionaries are supposed to behave
 per WebIDL. They are defined to ignore all properties not defined by
 the dictionary IDL. So we should remove this exception and also change
 the type of this argument to use IDBDatabaseOptionalParameters
 rather than Object.

Oh, and I should mention that I was the one originally pushing for the
throwing behavior here. However I was talked out of it by various
people that know JS better than me, both on this list and elsewhere.
The short answer is that looking for absence of properties any isn't a
very JS-esq thing to do. First of all properties often live on
prototype chains. For example every object has a toString property
since that property lives on the Object prototype.

So that's why the WebIDL spec doesn't throw for unknown properties,
and that's why I was talked out of it for IndexedDB too.

/ Jonas

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components