[Bug 16952] Add a Blob.close()

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

--- Comment #9 from Jonas Sicking <jonas@sicking.cc> 2012-07-03 22:05:13 UTC ---
Once a read has started, we should definitely not allow other in-browser APIs
to cause it to fail more or less stochastically. I.e. if someone writes a page
like:

var reader = new FileReader();
reader.readAsArrayBuffer(myblob);
setTimeout(function() {
  myblob.close();
}, 500);

Then this shouldn't fail in some browsers and work in others. Or work for users
with a fast filesystem but fail for users with a slow filesystem.

Exactly the same thing goes for

var xhr = new XMLHttpRequest();
xhr.open("GET", someurl);
xhr.send(myblob);
setTimeout(function() {
  myblob.close();
}, 500);


Likewise

var myurl = URL.createObjectURL(myblob);
imgElement.src = myurl;
setTimeout(function() {
  URL.revokeObjectURL(myurl);
}, 500);

should not fail or work depending on timing.

So any reads that have already started should not fail when Blob.close() or
URL.revokeObjectURL is invoked.


I disagree with the argument that this is just like if the user deletes the
file through the filesystem. First of all that means that the user has to take
explicit action, which is unlikely these days given that few users mess around
in the filesystem. It also is something that the user can prevent if he/she
realizes that things fail if they go and delete a file too quickly after doing
something with them in a webpage.

Second, the OS filesystem can be made to prevent the user from deleting the
file. I.e. if the browser keeps the file open in read mode while reading from
the file, then the user is either prevented from deleting the file (Windows),
or the file won't be truly deleted until the browser closes the file (Linux,
OSX).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 3 July 2012 22:05:14 UTC