W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Eric U <ericu@google.com>
Date: Tue, 20 Sep 2011 17:40:25 -0700
Message-ID: <CAHvSExe3aL3x6O0xtagvv6H1dD2kkGiTeor9vStB-yk9nbHuww@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Glenn Maynard <glenn@zewt.org>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Tue, Sep 20, 2011 at 8:01 PM, Eric U <ericu@google.com> wrote:
>>> I have a read running, and at some point I abort it--it could be in
>>> onprogress or elsewhere.  In onabort I start another read.  In
>>> onloadstart I abort again.  Repeat as many times as you like, then let
>>> a read complete.  I believe we've specced that the event sequence
>>> should look like this:
>>> loadstart
>>> [progress]*
>>> ------[events from here to XXX happen synchronously, with no queueing]
>>> abort
>>> loadstart
>>> abort
>>> loadstart
>> XHR handles this by not allowing a new request to be opened until the
>> abort() method terminates.  Could that be done here?  It seems like an
>> important thing to be consistent about.
>> http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-abort-method
> Ooh, that's a good idea.
> / Jonas

Indeed--however, from a quick skim of XHR and XHR2, that's not what
they do.  They let open() terminate abort(), however far along it's
gotten.  If we did that, then an abort killed by a read might lead to
the aborted read never getting an onloadend.  But you could still get
the stack-busting chain of onloadstart/onabort.

If we wanted to prevent read methods from being called during abort,
we'd probably want to do that by setting an "aborting" flag or mucking
around with yet another readyState of ABORTING.
Received on Wednesday, 21 September 2011 00:41:06 UTC

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