- From: Eric U <ericu@google.com>
- Date: Wed, 29 Feb 2012 15:44:45 -0800
- To: Arun Ranganathan <aranganathan@mozilla.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Feb 29, 2012 at 2:57 PM, Arun Ranganathan <aranganathan@mozilla.com> wrote: >> 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. Do you mean "if onload, onerror, or onabort..."? >> > 2. Simply not fire loadend on abort. I'm not sure this is a good >> > idea. Agreed. It should be there unless another read starts. >> > 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. I don't see a conflict--abort terminates read, and read terminates abort. Actually, if we really want to match XHR2, we should qualify all the places that we fire loadend. If the user calls XHR2's open in onerror or onload, that cancels its loadend. However, a simple check on readyState at step 6 won't do it. Because the user could call readAsText in onerror, then call abort in the second read's onloadstart, and we'd see readyState as DONE and fire loadend twice. To emulate XHR2 entirely, we'd need to have read methods dequeue any leftover tasks for previous read methods AND terminate the abort algorithm AND terminate the error algorithm of any previous read method. What a mess. Perhaps there's a simpler way to say "successfully calling a read method inhibits any previous read's loadend"? [steps 5 and 6 there are missing trailing periods, BTW]
Received on Wednesday, 29 February 2012 23:45:28 UTC