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

> > 
> > But developers SHOULD see the effect of blob.close(), and in places outside
> > of fetch! 
> 
> Can you give an example?  There might be use cases for a Blob.closed
> property to find out if a blob is closed (if we're OK with being locked into
> this being a sync operation), but that's all I can think of.


If a web app gets a file reference, allows it to be displayed, including with
metadata extraction (ID3 / EXIF), and then posted to the server with FormData,
but wants to close the object at some point.

The keepalive list posited in Bug 25302 might allow FormData to work even after
the Blob has been neutered, but other operations on that neutered Blob,
happening AFTER the closing, should know the Blob is closed, and maybe recreate
the file picker. 

Rather than throw on a subsequent read operation, we could return 0 bytes. This
makes it hard to differentiate between a *real* 0 byte Blob that is still
OPENED, and a CLOSED Blob. That is the problem Jonas identifies, but I'm not
sure what the use case would be for real 0 byte objects that aren't neutered.


> 
> (Of course, they should see the effect of disk space being freed up if
> things are working correctly, but that's not a *script-visible* effect.)
> 
> > Maybe the idea of a restricted keepalive list in bug 25302 is the right
> > approach.
> 
> (Sorry, I lost the thread--is this related?)


It's related in that I don't think the right approach is to retroactively close
all the parents of slices; I agree that a slice on a neutered Blob should also
be neutered, but I don't think neutering a slice neuters the parent (original
object).

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

Received on Wednesday, 9 April 2014 21:13:36 UTC