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

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

--- Comment #14 from Simon Pieters <simonp@opera.com> ---
(In reply to Arun from comment #13)
> 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).

OK... I don't follow what would be unpredictable, though.

> 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.

That seems wrong. Returning a blob URL that will result in a network error
seems OK, though. It's not clear to me which is better, but maybe throwing
early is more helpful for catching mistakes.

> BUT:
> 
> var blob = new Blob();
> var url = URL.createObjectURL(blob);
> 
> *also* returns a URL that can be used to Parse/Fetch on 0 bytes.

Indeed.

> 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 15:35:00 UTC