W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: FileReader abort, again

From: Eric U <ericu@google.com>
Date: Wed, 29 Feb 2012 14:30:12 -0800
Message-ID: <CAHvSExfFmU+4tpRW7pCQws8AydGFVfmNvin3cz-cmC9O8hvEvw@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
> FileReader.abort is like a bad penny :)
>> However, I'm not sure it quite matches the normative text in one
>> respect.  Where you say [8.5.6 step 4]: "Terminate any steps while
>> processing a read method."  Does that also terminate the steps
>> associated with an abort that terminated the read method?  Basically
>> I'm not sure what "steps while processing a read method" means.
> I've changed this to terminate only the read algorithm (and hopefully it is clear this isn't the same as the abort steps):
> http://dev.w3.org/2006/webapi/FileAPI/#terminate-an-algorithm and
>> Otherwise, if you start a new read in onabort [8.5.6 step 5], you'll
>> still deliver the loadend [8.5.6 step 6].
>> This contradicts "Once a loadstart has been fired, a
>> corresponding loadend fires at completion of the read, EXCEPT if the
>> read method has been cancelled using abort() and a new read method
>> has
>> been invoked."
> This seems like familiar ground, and I'm sorry this contradiction still exists.
> So we could:
> 1. Say not to fire a loadend if onloadend or onabort re-initiate a read.  But this may be odd in terms of analyzing a program before.
> 2. Simply not fire loadend on abort.  I'm not sure this is a good idea.
> What's your counsel?  Have I missed something easier?
> -- A*

My email must have crossed yours mid-flight, but just in case, how
about speccing that read* methods terminate the abort algorithm?
That's what XHR2 does, and it looks like it works.  It's not the
easiest thing to figure out when reading the spec.  It took me a while
to get my mind around it in XHR2, but then that's a much more
complicated spec.  FileReader's small enough that I think it's not
unreasonable, and of course matching XHR2 means fewer surprises all

Received on Wednesday, 29 February 2012 22:30:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:31 UTC