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

On Wed, Sep 21, 2011 at 2:44 PM, Eric U <ericu@google.com> wrote:
> 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.

I think we're basically limited here by over 10 years of IE code.

For what it's worth, it's fairly easy for pages to avoid the problems
here. If a page listens to the loadend event, it should do any
aborting or new-load-starting here. If it doesn't listen to loadend,
then the event order it will see will be quite sensible. I.e. if you
remove loadend from the list of events that you had, it looks quite
logical.

/ Jonas

Received on Wednesday, 21 September 2011 21:53:06 UTC