- From: Arun Ranganathan <aranganathan@mozilla.com>
- Date: Wed, 29 Feb 2012 14:57:32 -0800 (PST)
- To: Eric U <ericu@google.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
> On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan > >> 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 8.5.9.2.1 "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* > > My email must have crossed yours mid-flight, but just in case, how > about speccing that read* methods terminate the abort algorithm? > That's what XHR2 does, and it looks like it works. It's not the > easiest thing to figure out when reading the spec. It took me a > while > to get my mind around it in XHR2, but then that's a much more > complicated spec. FileReader's small enough that I think it's not > unreasonable, and of course matching XHR2 means fewer surprises all > around. OK, I'll study XHR2 and figure this out. Spec'ing this isn't a quick win, though, since abort's role is to terminate a read*! So to have a re-initiated read* terminate an abort will require some thought on invocation order. -- A*
Received on Wednesday, 29 February 2012 22:58:00 UTC