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