- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 28 Mar 2012 01:51:59 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Glenn Maynard <glenn@zewt.org>, public-webapps WG <public-webapps@w3.org>
On Wed, Mar 28, 2012 at 2:17 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Wed, 28 Mar 2012 08:19:55 +0100, Jonas Sicking <jonas@sicking.cc> wrote: >> >> I think we need to define that APIs like xhr.open(...) and the img.src >> setter synchronously "dereference" the URL before returning. > > What does dereferencing mean exactly? It means "initiating the load" or some such. Implementation-wise for blob URLs it would likely mean going through the blob-url hash table to find the underlying Blob object and start a read from it. So if the URL is removed from the hash using revokeObjectURL this wouldn't affect the load. Likewise for the FileSystem API it would mean that a read from the blob has started and so any writes need to be queued until after the read is finished. > xhr.open() resolves URLs currently and then xhr.send() will fetch the URL. Yup, this is the stuff that needs to be defined. In Gecko we actually "dereference" the URL in xhr.open which means that the caller can call revokeObjectURL after the call to xhr.open but before xhr.send. But it's certainly possible to change this so that the URL is dereferenced in xhr.send instead. / Jonas
Received on Wednesday, 28 March 2012 08:52:59 UTC