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 15:00:36 -0700
Message-ID: <CA+c2ei-03eQNenYd5q8Bm=jo9CKGaA16WGnLiLePPqJe5MBGOw@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: arun@mozilla.com, Eric U <ericu@google.com>, Glenn Maynard <glenn@zewt.org>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 29 Sep 2011 23:17:21 +0200, Eric U <ericu@google.com> wrote:
>> I think that works; #2 will be especially important.
>> However, if I read this right, we *don't* have the invariant that a
>> loadstart will always have a loadend.
>> Now that Anne's explained XHR2's model, it seems that an open can
>> cancel the loadend that an abort would have sent.  So the invariants
>> need to be a bit more complex.
> Well lets not accept as XHR2 as set-in-stone.
> We could also change XHR2 to not cancel abort() when invoking open(). Then
> you get scenarios such as:
>  abort()
>  -> abort event that invokes open()
>     -> readystatechange event
>  -> loadend event
>  -> abort event on XHRUpload
>  -> loadend event on XHRUpload
> Instead of everything after the readystatechange event not happening. We
> could also introduce a flag and make it impossible to call open() from an
> event handler.
> Maybe the simplest is the above. You can call open() from event handlers,
> but events will still be dispatched (and readyState will have changed). This
> is somewhat ugly, but then you should probably not invoke open() from event
> handlers anyway.

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.

In the first case it makes sense to call .open/.send from the onerror
handler. In the second case it makes sense to do so from the onabort

I'm personally split on the issue. On one hand I really like the
simplicity of saying that each "loadstart" is always paired with a
"loadend". On the other hand, I have a hard time thinking of any use
cases which *wouldn't* be helped by simply dropping the "loadend"
event if a new load had been started.

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 ;-)

/ Jonas
Received on Monday, 3 October 2011 22:01:36 UTC

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