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

Gmail rather unhelpfully linked to the tests in the text/html version of my
earlier mail with links that didn't match the text.  Fixed (hopefully):

[1] https://zewt.org/~glenn/test-open-during-onabort.html#http/onabort (HTTP
timeout)
[2] https://zewt.org/~glenn/test-open-during-onabort.html#tcp/onabort (TCP
timeout)
[3] https://zewt.org/~glenn/test-open-during-onabort.html#http/onloadend
[4] https://zewt.org/~glenn/test-open-during-onabort.html#tcp/onloadend

On Sat, Oct 1, 2011 at 2:25 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Fri, 30 Sep 2011 19:15:17 +0200, Arun Ranganathan <arun@mozilla.com>
> wrote:
>
>> Anne: I think simplifying the model like this makes sense, although
>> previous discussions seemed to suggest that previous implementation history
>> made these kinds of changes hard.  I'd be happy to match this in FileReader
>> if that's what you're doing in XHR2.
>>
>
> I believe Glenn said this is what Gecko is doing now (rather than what the
> standard says).


If the server it's connecting to is unreachable and not opening the TCP
connection at all, you'll get the exception; if the connection opens but the
actual HTTP request takes a long time, you won't.  Any site could hit the
exception, I think, if the user's connection is slow.


On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 1. Make "loadend" not fire in case a new load is started from
> onabort/onload/onerror. Thus "loadend" and "loadstart" isn't always
> paired up. Though there is always a "loadend" fired after every
> "loadstart".
> 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also

leaves the problem unsolved for XHR.


> Are there other options I'm missing?
>

Or do both, improving XHR as much as backwards-compatibility allows and
don't try to match other APIs to it exactly.  I'd much prefer weirdness be
isolated to XHR than be perpetuated through every PE-based API.

-- 
Glenn Maynard