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

On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Nov 2, 2011 at 9:56 AM, Eric U <ericu@google.com> wrote:
>> On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard <glenn@zewt.org> wrote:
>>>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking <jonas@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.
>>
>> I'm for this.  It lets FileReader and FileWriter match XHR, avoids [in
>> the odd case] long strings of stacked-up loadend events, and users can
>> avoid all the issues either by creating a new FileReader or by
>> wrapping nested calls in timers if they care.  I believe Jonas is in
>> favor of this as well.
>>
>> Can we put this one to bed?
>
> So the proposal here is to allow new loads to be started from within
> abort/error/load event handlers, and for "loadend" to *not* fire if a
> new load has already started by the time the abort/error/load event is
> done firing. And the goal is that XMLHttpRequest, FileReader and
> FileWriter all behave this way. Is this correct?

I think I may have missed something important.  XHR2 specs just this
behavior w.r.t. abort [another open will stop the abort's loadend] but
/doesn't/ spec that for error or load.  That is, an open() in onerror
or onload does not appear to cancel the pending loadend.  Anne, can
you comment on why?

> If so, I agree that this sounds like a good solution.
>
> / Jonas
>

Received on Wednesday, 2 November 2011 23:08:36 UTC