[Bug 24576] Calling URL.createObjectURL() on a closed Blob

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

--- Comment #13 from Arun <arun@mozilla.com> ---
(In reply to Simon Pieters from comment #12)
> (In reply to Arun from comment #9)
> > What should happen here IMHO is that if the read is underway, close()
> > shouldn't have an effect. Of course, subsequent async reads will fail.
> > 
> > This should be made clearer. I don't think we can/should disrupt a read
> > that's underway. Do you agree?
> 
> That sounds good to me. The spec seems clearer now than when I wrote the
> earlier comment, IIRC.


OK; a separate bug to either make the read operation fully asynchronous or
synchronous with a wrapper is Bug 25081 and depending on how that shakes out,
this could change slightly.


> 
> > This should throw:
> > 
> > var blob = new Blob(); blob.close(); URL.createObjectURL(blob);
> 
> Why?


Well, the reasoning is that read operations throw when you try to read a closed
Blob. I think this seems about right. So, minting a blob URL on a closed blob
should also throw, since that's a type of read but by another name (Parse/Fetch
-- we should fail them aggressively right out of the starter gate, rather than
have unpredictable Parse/Fetch behavior).

Alternatively, we could specify that it doesn't throw, but instead returns a
blob URL that can be used for Parse/Fetch on 0 bytes. BUT:

var blob = new Blob();
var url = URL.createObjectURL(blob);

*also* returns a URL that can be used to Parse/Fetch on 0 bytes.

The difference is that this by design; calling blob.close(), however, is a
programmatic declaration that the Blob should be closed and memory should be
culled.

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

Received on Wednesday, 19 March 2014 14:58:11 UTC