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

On Thu, Sep 29, 2011 at 12:22 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>
> On 9/21/11 8:07 PM, Eric U wrote:
>>
>> Update: I have made the changes to FileWriter/FileSaver's event
>> sequences; they now match FileReader.
>> That's not to say it won't change pending discussion, but FileWriter
>> should continue to match FileReader whatever else happens.
>>
>>       Eric
>
> Eric:
>
> After reading this email thread, and looking at your changes, I think I'll make the following changes:
>
> 1. Tighten requirement on onprogress such that we mandate firing *at least one* progress event with a must.  Right now this is unclear as you point out, not least of all because we don't mandate the user agent calling onprogress.
> 2. Include a discussion of the invariants Jonas mentions [1], so that event order is fleshed in the event section.
> 3. Clarify exceptions to the 50ms event dispatch timeframe (notably for progress events before load+loadend).
>
> To be clear, you've decided we're NOT going to veer from XHR2's abort/open behavior (and thus what FileReader says now) in FileWriter/FileSaver right?
>
> Is this a good summary of changes that we should make?
>
> -- A*
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1512.html

I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's explained XHR2's model, it seems that an open can
cancel the loadend that an abort would have sent.  So the invariants
need to be a bit more complex.

I've updated FileWriter to take most of this into account, but *not*
that last bit yet; as written, I've got Jonas's original invariants,
which would lead to the stacked up loadend events at the end.

Received on Thursday, 29 September 2011 21:18:02 UTC