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 17:10:29 -0700
Message-ID: <CA+c2ei_X7-2fDK02sFgt0h14FGPjsKTHKezV1CjuhVQoG5hT2A@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 4:16 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Unfortunately I suspect wanting to call open from event handlers is a
>> pretty common use case. Here are two use cases:
>> 1. In case of a network error, let the onerror handler retry the request.
>> 2. Implementing a auto-complete UI backed by data stored on the
>> server. Any time the user hits another character, abort the current
>> request and perform a new request with the newly typed value.
> These can be handled trivially by wrapping in a timer.  This is a basic
> platform concept, an approximation of "queue a task" so common in specs.
> (#2 isn't actually a problem, since it's an event from a different
> source--it's only recursing back into the same XHR/FileReader/etc. object
> from its own events that causes ugliness.)
>> For example if you're implementing a progress bar, it would be very
>> easy to make the mistake of hiding the progress bar from "loadend" and
>> showing it in "loadstart". In the two use cases above, that would
>> result in the progress bar not showing during the second load. I'll
>> leave as an exercise to the reader how to avoid such a bug ;-)
> This shouldn't be a "mistake"--it's the natural, obvious way to use these
> events.  You shouldn't have to worry about receiving two loadstarts in a
> row, or two loadends in a row, or missing loadends, depending on what object
> is firing the event, how its API is being used, or where your event listener
> is in the event handler list.


> Needing to use setTimeout in some cases is a tiny price to pay, to avoid
> having to worry about that mess and keep these events straightforward and
> predictable.

Except that we can't do that for XHR since there's already tons of
content out there. Most likely enough of that content starts a new
load from onabort/onload/onerror that we can't make that throw. Which
leaves us with the following options:

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
2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also
leaves the problem unsolved for XHR.

Are there other options I'm missing?

/ Jonas
Received on Tuesday, 4 October 2011 00:11:28 UTC

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