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

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.

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

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

-- 
Glenn Maynard