- From: <bugzilla@jessica.w3.org>
- Date: Fri, 07 Feb 2014 15:35:32 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24576 --- Comment #3 from Arun <arun@mozilla.com> --- (In reply to Simon Pieters from comment #2) > I think close() should only set a flag on the Blob and then the relevant > algorithms that need to care about it look at that flag (getting size, > dereferencing blob: URL, whatever else). That would be clearer than the > current requirement for close(). This sounds right to me, and is how I've begun to specify it. I think the flag should be an internal state keeper, and shouldn't really be an additional property on the Blob object. A Blob that's been neutered with a close() call has a state of CLOSED; otherwise OPENED (or something similar). Then: 1. Both synchronous and asynchronous "read" will check for this state; the FileReader[Sync].readAsXXX will do the appropriate thing (error event or throw). 2. Blob.close() will also force the same sequence of steps as URL.revokeObjectURL(URL); essentially, a CLOSED Blob will be expunged from the Blob URL Store, and subsequent URL Parse will fail. A question remains about whether asynchronous fetch actions should *also* fail, but I don't think so right now. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 7 February 2014 15:35:33 UTC