W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 3 Oct 2011 18:13:25 -0700
Message-ID: <CA+c2ei_4U=EXrrrA7H2aQEtLTvMjt8aAALDdZVCHE8V3Oz+3JA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
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.

/ Jonas

/ Jonas
Received on Tuesday, 4 October 2011 01:14:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC