On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman <[email protected]> wrote:
> On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
>> On 4/15/11 2:57 PM, Adrian Bateman wrote:
>> > With this in mind, I don't personally have a strong feeling either way
>> > between having to call abort() explicitly or having readAsXXX implicitly
>> > call abort(). I've discussed it with others at Microsoft this week and the
>> > consensus here is that the defensive exception is better and that
>> > developers
>> > should have to call abort() if they want to abandon the current operation.
>> > I think we could live with either but right now we're planning for throwing
>> > the exception. We'd like to make a decision one way or the other pretty
>> > soon.
>>
>> Adrian: I'm keen to have behavior similar to XHR, and not raise an
>> exception in this case. From your note above, I'm gathering you can
>> live with an XHR-style abort which FileReader can fire on readAsXXX
>> calls that have been superseded.
>
> Yes, we could live with it but the semantics are more complex. Is this the
> same
> as calling abort() then readAsXXX()?
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress)
abort();
... start new reading ...
}
> When does the abort event get queued? What
> will be the state of the reader at this point? Will loadend get fired? It
> needs
> careful speccing to make sure that the details are handled the same in
> different
> implementations.
>
Calling the abort() fires the "abort" and "loadend" events before the
function returns. Likewise readAsX fires the "loadstart" event before
it returns. So if a load has already started, then readAsX fires,
before it returns, the following events in order:
"abort", "loadend", "loadstart"
But indeed, the spec needs improvements here.
/ Jonas
