On Mon, Mar 5, 2012 at 2:01 PM, Eric U <er...@google.com> wrote: > On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan > <aranganat...@mozilla.com> wrote: >> 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. > > Ah, right--so a new read initiated from onload or onerror would NOT > suppress the loadend of the first read. And I believe that this > matches XHR2, so we're good. Nevermind.
No, I retract that. In http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1627.html Anne confirmed that a new open in onerror or onload /would/ suppress the loadend of the first send. So we would want a new read/write in onload or onerror to do the same, not just those in onabort. >>> 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? > > I'm not sure why it's any more confusing that read* is open+send. > read* can cancel abort, and abort can cancel read*. OK. > > >>> 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. > > Hack 1: Don't call loadend synchronously. Enqueue it, and let read* > methods clear the queues when they start up. This differs from XHR, > though, and is a little odd. Still works, but needs to be applied in multiple places. > Hack 2: Add a virtual generation counter/timestamp, not exposed to > script. Increment it in read*, check it in abort before sending > loadend. This is kind of complex, but works [and might be how I end > up implementing this in Chrome]. Still works, but needs to be applied in multiple places. > But really, I don't think either of those is better than just saying, > in read*, something like "terminate the algorithm for any abort > sequence being processed". ...or any previously-initiated read being processed.