W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Eric U <ericu@google.com>
Date: Wed, 21 Sep 2011 16:51:13 -0700
Message-ID: <CAHvSExdU3aduikW2P4PfdZmatHqzqjFNZR3iemfzj02rnM9wuQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
On Wed, Sep 21, 2011 at 4:45 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Sep 21, 2011 at 6:51 PM, Eric U <ericu@google.com> wrote:
>>
>> While it's certainly not hard to work around, as you say, it seems
>> more complex and less likely to be obvious than the
>> counter-for-activity example, which feels like the classic push-pop
>> paradigm.
>
> The *need* to have counters to use loadstart/loadend at all isn't obvious,
> and it's a guarantee that many (perhaps most) users won't do this.  Pulling
> code out of events with a timer isn't at all complex--it's a simple, common
> pattern.  I think it's much more obvious, since if you don't do it an
> exception is raised (that you can search for if you don't know what to do),
> instead of a subtle bug being introduced.
>
> Also note that XHR cancels the abort method entirely if you start a new
> request during onabort, which means loadend isn't fired.  Having mismatched
> loadstart/loadend events seems equally ugly, and not something to try to be
> consistent with even if we're stuck with it for XHR.

Again, that's not what the XHR2 spec says.  See my summary up-thread
about the actual behavior, and Anne can correct my interpretation if
I'm wrong.

>> And expecting users to write their event handlers one way
>> for XHR and a different way for FileReader/FileWriter seems like
>> asking for trouble--you're going to get issues that only come up in
>> exceptional cases, and involve a fairly subtle reading of several
>> specs to get right.  I think we're better off going with consistency.
>
> You can write code for XHR in the same way, if you want, punting open()
> calls out of abort/loadend event handlers with a timer.  It'd be depressing
> to see PE turn so ugly in an attempt to be consistent with a flawed legacy
> API; better to isolate the problem as much as possible.  (Are there any
> other APIs with this problem besides XHR that couldn't be fixed?)

Expecting users to rewrite handlers for XHR to match a new API, where
it's not necessary for XHR's use, seems wildly optimistic.

> Another way to deal with this is to make loadstart (and other parts of those
> calls, the error paths in particular) async, so if you start a new read
> within onabort, it won't actually start until the abort finishes.  (That's a
> more invasive behavioral change, of course, and I'm not sure I'd like it
> myself, but it's worth at least mentioning.)

That has other issues.  If you change readyState and call the handler
in separate actions [one immediate, one queued] you've got a strange
state in between.  On the other hand, if you don't change readyState
until the queued handler runs, you might try calling readAsText
multiple times, since nothing will [visibly] have changed.  Either of
those seems bad.
Received on Wednesday, 21 September 2011 23:51:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT