RE: FileReader abort, again

> 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.
We encountered this same ambiguity in the spec, and we agree with the above. This is also what we 
have implemented and shipped in the consumer preview.

> 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].
Of the list of 'hacks', we also implemented hack #2 to get the correct behavior.



> -----Original Message-----
> From: Eric U [mailto:ericu@google.com]
> Sent: Tuesday, March 06, 2012 12:16 PM
> To: Arun Ranganathan
> Cc: Web Applications Working Group WG
> Subject: Re: FileReader abort, again
> 
> 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 Wednesday, 7 March 2012 00:48:58 UTC