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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25242

--- Comment #3 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #0)
> 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.


Behaving as if a network resource is no longer available is right behavior, but
only for Blobs that are accessed by network APIs. This behavior sounds right
for CLOSED blobs that are used to coin blob: URLs. In this case, this behavior
makes sense.


> 
> 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).


OK, I think this makes sense. That is, the overall technical consensus seems to
be to simply NOT true.

And this applies to Blobs that you call .close() on before you .slice() them.


> 
> 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.


But developers SHOULD see the effect of blob.close(), and in places outside of
fetch! 

Maybe the idea of a restricted keepalive list in bug 25302 is the right
approach.



> 
> 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, 9 April 2014 20:05:50 UTC