W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

[Bug 25242] New: Blob.close should not set the blob's size to 0 or cause slice() to throw

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Apr 2014 23:56:27 +0000
To: public-webapps@w3.org
Message-ID: <bug-25242-2927@http.www.w3.org/Bugs/Public/>
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 on the CC list for the bug.
Received on Wednesday, 2 April 2014 23:56:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:23 UTC