[Bug 25081] Make read operation really async

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081

--- Comment #16 from Arun <arun@mozilla.com> ---
(In reply to Anne from comment #15)
> You're a bit late to the party :-) In some other bug we reached that
> conclusion already. I'm not sure if submission should necessarily fail.
> Whether cloning a closed blob fails or whether it just returns a new closed
> blob of which reading returns the empty byte sequence is still under
> discussion.


... or in fact if reading a closed blob simply returns failure, and not 0
bytes: this is Bug 25242. There's an additional point that a closed Blob should
only cause read failure, either for asynchronous or synchronous reads, and that
read failure should be the only thing that fails on closed blobs. This means
that structured cloning works on a closed blob, contrary to 

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

If you serialize for FormData, then at the point of read you'll get a failure
on the close Blob.

It's been argued that a check for a closed blob in the read operation disrupts
the asynchrony of the read operation (the original point of this bug!!!) but I
think that if reading a closed blob fails, the generic read operation should
return failure and a failure reason.

That means tweaking http://dev.w3.org/2006/webapi/FileAPI/#readOperationSection
 a bit to do the right thing with failure reasons. But I think it's mostly ok
at this point.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 15 April 2014 23:00:58 UTC