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

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

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


My use of "unpredictable" is misleading. It wouldn't be unpredictable, because
it would follow behavior that we specify :-) Instead of "unpredictable" I
meant: you'd get something like 0 bytes or a network error, without immediately
knowing that the blob was closed, and thus was a no-op for all practical
purposes anyway.

The two sane choices are network error vs. throwing. I favor throwing.

> 
> > 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 17:22:05 UTC