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 <[email protected]> wrote: > On Fri, 30 Sep 2011 19:15:17 +0200, Arun Ranganathan <[email protected]> > 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 <[email protected]> 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
