- From: Eric U <ericu@google.com>
- Date: Tue, 6 Mar 2012 12:15:44 -0800
- To: Arun Ranganathan <aranganathan@mozilla.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Mar 5, 2012 at 2:01 PM, Eric U <ericu@google.com> wrote: > On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan > <aranganathan@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.
Received on Tuesday, 6 March 2012 20:16:36 UTC