- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Apr 2014 23:56:27 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25242 Bug ID: 25242 Summary: Blob.close should not set the blob's size to 0 or cause slice() to throw Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: File API Assignee: arun@mozilla.com Reporter: glenn@zewt.org QA Contact: public-webapps-bugzilla@w3.org CC: public-webapps@w3.org Blob objects should be immutable, as if their data and its size never change. Blob.close() should cause reads to the blob to behave as though a network resource is no longer available. This fulfills the goal of Blob.close (discarding the underlying storage), without losing immutability of the Blob interface itself. Similarly, blob.slice() with a closed Blob shouldn't throw. Just create a new Blob just as you would if the original blob wasn't closed, and mark the new blob closed. This is also consistent with bug 24576 (making createObjectURL not throw). Another benefit of these changes is that the effects of Blob.close() are narrowed. Its only (script visible) effects during fetch, instead of having lots of little side-effects scattered across the whole Blob API. That makes the API simpler for developers. It may also make it easier to have a later Blob.close() variant that also closes all slices of the blob. Right now it's actually fairly hard to successfully close a Blob, since you need to close every sub-slice that you create, too. Doing a Blob.close({includingSlices: true}) may be easier later if we eliminate these synchronous side-effects, since this could cross workers. (Also related to bug 25240.) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 2 April 2014 23:56:29 UTC