Eric, > >> > So we could: > >> > 1. Say not to fire a loadend if onloadend or onabort > > Do you mean "if onload, onerror, or onabort..."?
No, actually. I'm looking for the right sequence of steps that results in abort's loadend not firing if terminated by another read*. Since abort will fire an abort event and a loadened event as spec'd (http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort), if *those* event handlers initiate a readAs*, we could then suppress abort's loadend. This seems messy. > > 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. This may be the way to do it. The problem with emulating XHR2 is that open() and send() are distinct concepts in XHR2, but in FileAPI, they are the same. So in XHR2 an open() canceling abort does make sense; abort() cancels a send(), and thus an open() should cancel an abort(). But in FileAPI, our readAs* methods are equivalent to *both* open() and send(). In FileAPI, an abort() cancels a readAs*; we now have a scenario where a readAs* may cancel an abort(). How to make that clear? > Perhaps there's a simpler way to say "successfully calling a read > method inhibits any previous read's loadend"? I'm in favor of any shorthand :) But this may not do justice to each readAs* algorithm being better defined. -- A*
