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

On Tue, Sep 20, 2011 at 8:40 PM, Eric U <ericu@google.com> wrote:

> Indeed--however, from a quick skim of XHR and XHR2, that's not what
> they do.  They let open() terminate abort(), however far along it's
> gotten.  If we did that, then an abort killed by a read might lead to
> the aborted read never getting an onloadend.  But you could still get
> the stack-busting chain of onloadstart/onabort.
>

Yuck.  I agree that's not a good thing to mimic for the sake of
consistency.  Anne, is this intentional, or just something XHR is just stuck
with for compatibility?  It looks like a new problem in XHR2--this couldn't
happen in XHR1, because there was no abort event fired before loadend.

If we wanted to prevent read methods from being called during abort,
> we'd probably want to do that by setting an "aborting" flag or mucking
> around with yet another readyState of ABORTING.
>

That's annoying, but it's better than the current situation, and I think
better than the XHR situation.  Receiving loadstart should guarantee the
receipt of loadend.

On Tue, Sep 20, 2011 at 7:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 1. onloadstart fires exactly once
> 2. There will be one onprogress event fired when 100% progress is reached
> 3. Exactly one of onabort, onload and onerror fires
> 4. onloadend fires exactly once.
> 6. no onprogress events fire before onloadstart
> 5. no onprogress events fire after onabort/onload/onerror
> 6. no onabort/onoad/onerror events fire after onloadend
>

7. after loadstart is fired, loadstart is not fired again until loadend has
been fired (ie. only one set of progress events can be active on an object
at one time).

More precisely: loadstart should not be fired again until the dispatch of
loadend *has completed*.  That is, you can't start a new progress sequence
from within loadend, either, because there may be other listeners on the
object that havn't yet received the loadend.

-- 
Glenn Maynard