In general we are OK with changing it to the autoRevoke behavior below, but 
have some concerns around changing the default behavior. 
Changing the default behavior is a breaking change and any apps which expect 
the URL to work multiple times will now be broken. In Windows 8, we also 
implemented the oneTimeOnly behavior and it was very widely used, these 
consumers will be broken as well.  

We would like to support autoRevoke as the default as it helps reduce the 
chance of leaking unintentionally, but  we think developers should have a way 
to feature detect the new change. If a developer can feature detect which 
default behavior is present, then they can reason about what to expect from the 

If a way is provided for developers to detect the change, then we support this 
change. Additionally, we support the changes outlined in the bug at, and feel it resolves 
several of the edge cases we saw when implementing the File API.

From: Arun Ranganathan [] 
Sent: Wednesday, July 11, 2012 1:20 PM
To: Glenn Maynard
Cc: Rich Tibbett; public-webapps; Arun Ranganathan; Jonas Sicking
Subject: Re: [File API] Blob URI creation

On May 30, 2012, at 6:48 PM, Glenn Maynard wrote:

On your main question, I've had the same thought in the past--a "url" property 
on Blob which simply creates a new auto-revoking blob URL.  I didn't bring it 
up since I'm not sure if creating a URL for a blob is actually something you do 
so often that it's worth having a shortcut.  If so, a function is probably 
better than a property--more future-proof, and it'd be unusual on the platform 
to have a property that returns a different value every time you read it.

On Wed, May 30, 2012 at 1:50 PM, Rich Tibbett <> wrote:
Yes, this might be a better solution. I was working on what was available in 
the editor's draft and looking for a way to remove the need to ever call 

This is part of what's wrong with oneTimeOnly--it *doesn't* actually completely 
remove the need to call revokeObjectUrl.  For example:

function f(blob) {
    var url = URL.createObjectURL(blob, {oneTimeOnly: true});
        img.src = url;

Without the revoke case, the URL (and so the whole blob) is leaked as it's 
never actually used.  autoRevoke doesn't have this problem.

Arun/Jonas: Can we hide this feature in the spec before more people implement 
it, or at least tag it with "not ready for implementations" or something?

I'll do one better, and introduce autoRevoke semantics:

By default, this does not need a corresponding revokeObjectURL() call.  In 
order for Blob URLs to persist past a stable state (for that unit of script) 
createObjectURL has to be invoked with autoRevoke set to false.

That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL 
through revokeObjectUrl because it assumes some auto-revocation behavior. Using 
microtasks to release at the next stable state does seem ok as long as 
developers have a very good understanding of when a Blob URI will be implicitly 
revoked. Saying that you can use a Blob URI exactly once, as per onetimeonly 
could still end up being easier to understand though.

(s/microtasks/stable states/; they're not quite the same)
It's actually a bit hard to understand (or easy to misunderstand), since 
there's no clear concept of "using a URL".  For example, if you start two XHR's 
on the same URL one after the other in the same script, the order in which the 
fetches actually begin is undefined (they happen in different task queues), so 
which would succeed is undefined.  (Some work would also be needed here for the 
autoRevoke approach, but it's much simpler.)

autoRevoke is pretty simple from the user's perspective: the URL is revoked 
when your script returns to the browser.

In fact, I think this addresses the lion's share of use cases, and if a 
developer wants to explicitly create "longer lasting" Blob URLs, they have that 
option (just not by default).

-- A*

Reply via email to