Re: [FileAPI] Result of calling MultipleReads on FileReader

On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman <adrianba@microsoft.com> 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