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

On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard <glenn@zewt.org> wrote:
>> 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.
>
> I don't think we can do that for XHR without breaking backwards compat.

I just spent a bit more time with the XHR2 spec, and it looks like the
same looping behavior's legal there too, bouncing between
onreadystatechange and onabort, and stacking up a pending call to
onloadend for each loop.  When open terminates abort, abort completes
the "step" of the algorithm [here step 5], which includes a subsequent
call to onloadend.  It's not a queued task to be cancelled, as it's
all synchronous calls back and forth.

If we want the file specs to match the XHR spec, then we can just
leave this as it is in File Reader, and I'll match it in File Writer.
Recursion depth limit is up to the UA to set.  But I look forward to
hearing what Anne has to say about it before we settle on copying it.

Received on Wednesday, 21 September 2011 21:44:44 UTC