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

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 UTC