- From: <bugzilla@jessica.w3.org>
- Date: Wed, 19 Mar 2014 15:34:58 +0000
- To: public-webapps-bugzilla@w3.org
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