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.

Reply via email to