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: Wed, 21 Sep 2011 17:32:45 -0700
Message-ID: <CAHvSExcf_0+iMYX=HBpeEbMQJpjZkJuP4j+6XTYsNqsp5rJQuA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Sep 21, 2011 at 7:51 PM, Eric U <ericu@google.com> wrote:
>>
>> Again, that's not what the XHR2 spec says.  See my summary up-thread
>> about the actual behavior, and Anne can correct my interpretation if
>> I'm wrong.
>
> I don't know what you mean by "again"; this is the first time I've described
> this behavior.

I was merely referring to
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1515.html,
to which I responded in
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1517.html.

> The spec says "The abort() algorithm can only be terminated by invoking
> open() from an event handler."  If you call open() from 5.6.2's onabort,
> then step 14 of the open() algorithm terminates abort(), and step 5.6.3
> never happens, thus onloadend is never fired and loadstart and loadend
> events are mismatched.

5.6.3 is a "substep", not a "step"; all of 5's substeps are referred
to as such in step 5: "Otherwise run these substeps:".  However, I
believe we were actually discussing 5.5, loadend on the XHR itself.
Either way, the below applies to both.

Regarding what happens on abort:

"This algorithm can be terminated by invoking the open() method. When
it is terminated the user agent must terminate the algorithm after
finishing the step it is on."

I read that as saying that if you call open while in onabort [5.4], it
completes step 5, including all of substep 5.6, including 5.5 and
5.6.3.  Do you think I'm mistaken?  I haven't run any test cases.

>> Expecting users to rewrite handlers for XHR to match a new API, where
>> it's not necessary for XHR's use, seems wildly optimistic.
>
> I don't know what you're referring to.  If it clearly doesn't work (because
> it's throwing an exception), they have to change their code, and it'll be
> immediately obvious that they need to do so; there's no optimism involved.

My point was that if it doesn't throw an exception in XHR, they won't
write their XHR handlers that way.  And so they haven't, and have
legacy code.  And when they add FileWriter handlers, they'll copy the
XHR code, and it will work most of the time, because an abort is an
exceptional case, and then it will fail in the field.
Received on Thursday, 22 September 2011 00:33:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT