Re: File API: closed Blob objects

On Dec 12, 2013, at 2:01 PM, Jonas Sicking wrote:

> 
> On Dec 12, 2013 9:55 AM, "Arun Ranganathan" <arun@mozilla.com> wrote:Reading from a Blob that has been closed() is a developer error with high degree of certainty. Nothing useful can come out of that.
> 
> So I think we do the developer a benefit by treating it as such and signaling an error through whatever mechanism is appropriate depending on how the reading was done.
> 
> We can certainly debate if throwing an exception or if asynchronously reporting a network error is the right thing to do for things like XHR.send(closedBlob) or FileReader.readAsX(closedBlob).
> 

So right now (in spec.) any Blob URL operations on a closed Blob must result in a network error. FileReader.readAsX(closedBlob) operations are equivalent to reading a Blob of size 0.  

I can understand the argument that the above might be a bit inconsistent; after all, we could do a Blob URL operation on a Blob of size 0 (where nothing happens, since no bytes are fetched), just as we allow FileReader reads on a resource of size 0 (e.g. result is a 0 bytes ArrayBuffer).   We should pick one thing: treat it as 0, and proceed accordingly (often, this is silent failure), or treat it as something that should be reported back as an error.

If we go the throw or error route, since we've already spec'd a network error for fetched Blob URLs when the underlying Blob has been closed with .close(), the choice of what to do for FileReader.readAsX(closedBlob) is whether to throw or to asynchronously use an error event with a DOMError (possibly with a NotReadableError).   

On December 12, 2013 at 2:06 PM, bzbarsky wrote:
>> Or form submission after fileInput.files[0].close() ?

This example makes me think that on balance, for consistency, maybe we should throw, and so should XHR.send(closedBlob).

-- A*