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

Re: FileReader abort, again

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Wed, 29 Feb 2012 13:43:13 -0800 (PST)
To: Eric U <ericu@google.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-ID: <1914948768.1911057.1330551793017.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
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*
Received on Wednesday, 29 February 2012 21:43:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC