Re: File API: auto-revoking blob URLs

On Wed, Apr 17, 2013 at 4:58 AM, Anne van Kesteren <>wrote:

> In roc suggests
> the default cannot be changed from no auto-revoking to auto-revoking.
> (And that we'll have mediastream URLs too.) Given that, I kinda doubt
> anyone will opt into setting autoRevoke to true... We could maybe
> create a different API that does the "right thing" but then "right
> thing" has not had much interest from implementers thus far (when it
> comes to the details).

I hope we can change the default, but auto-revoke is important whether we
can or not.

And again, we need to solve the blob data capturing problem anyway, because
it's a problem for manual blob URLs too (the problems are just not as
pronounced).  Currently the precise point where the fetch will no longer
fail because of a revoked blob URL is badly underdefined.  Even if you
assume "dereferenced" happens some time during fetch, the result is bad
interop, since it ends up depending on async task ordering, gets bit by the
"loads image data on demand" issue, etc.

For example, works
consistently in both Firefox and Chrome, which isn't clear from the specs. work in Chrome, but fails
in Firefox with a mysterious "not well-formed" log followed by some

On Wed, Apr 17, 2013 at 8:07 AM, Anne van Kesteren <> wrote:

>   <div>.style.backgroundImage = "url(" + url + ")"
>   <img>.src = url
>   <img>.srcset = "1x" + url + ", 2x " + url2
>"GET", url)
>   <style> body { background:url(url) } </style>
> "deferenced"?

Are you asking when it should happen, or when the specs say they do?  No
spec defines it today, which is what we're trying to fix.  My proposal
would do it synchronously on assignment.  The CSS path is harder if its
parse time isn't clearly defined, and if that can't be fixed then it may be
impossible to support blob URLs with CSS interoperably, and we'll have to
pick whether to live with the interop issues or to not support blob URLs in
CSS at all (probably too late for that).

Again, this is for all blob URLs, not just autorevoke ones.

Glenn Maynard

Received on Wednesday, 17 April 2013 13:25:48 UTC