[Bug 25302] Blob objects should have a keepalive list of objects

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

--- Comment #9 from Arun <arun@mozilla.com> ---
(In reply to Anne from comment #8)
> Yeah, defining this as a structured clone is what
> http://url.spec.whatwg.org/ does today and should work for FormData with
> some hassle.
> 
> It's not an implementation detail. It's important.
> 
> It's still unclear from the specification how operations need to deal with
> neutered blobs...


I think we're moving towards a Blob closure model where:

1. Objects requiring asynchronous access to Blobs work on structured clones of
the Blob in question. This obviates the need for a keepalive list of objects. 

2. Read operation(s) return failure on closed Blobs, and not 0 bytes, along
with a failure reason. Methods using read operation should handle the failure
asynchronously, or throw if they are synchronously invoking the read operation
(very rare -- synchronous reading of Blobs happen only on threads now). I've
come around to agreeing that 0 bytes isn't the right "test" for a closed Blob,
and is too ambiguous. There will be a property exposed on Blobs called
isClosed, a boolean, in case in-script checks are needed (this is Bug 25343 --
please submit usecases for the property there).

3. Nothing else fails on a closed Blob. You can still generate a Blob URL
through URL.createFor or URL.createObjectURL, but it will return a network
error. So the FormData case works on serialization, but fails on actual read
operation use.

Point 3. above may mean that structured cloning of a closed Blob actually works
(contrary to
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data). 

In short, the *only* point of failure on a closed Blob is a read operation.
Would this work?

The biggest "non spec" problem is determining a sufficient cue to GC a closed
Blob, since if some operations work (but read doesn't), then they may still
need to be around. But close still helps with memory management, because a read
operation won't transfer bytes to memory on closure.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 15 April 2014 23:17:15 UTC