Re: File API: auto-revoking blob URLs

On Mon, Apr 15, 2013 at 1:49 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> So blob URLs are auto-revoked by default after the current script
> stops running. However, every fetch operation in existence (apart from
> synchronous XMLHttpRequest) does so asynchronous.
>
> So
>
> <img>.src = blobURL
>

For anyone not familiar with this discussion, see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 for some of the prior
discussion.

This problem isn't limited to auto-revoking blobs.  UAs that "obtain images
on demand" won't invoke fetch synchronously at all, which causes similar
problems.  (I think the only major UA in that category is Opera.)

The solution I propose is the same as it's always been.  Have a synchronous
algorithm, eg. "parse and capture the URL", which is invoked at the time
(eg.) .src is set.  This 1: invokes the URL spec's parser; 2: if the result
is a blob URL, grabs the associated blob data and puts a reference to it in
the resulting parsed URL; then 3: returns the result.  Assigning .src would
then synchronously invoke this, so the blob is always captured immediately,
even if the fetch isn't.  This way, we can synchronously resolve all this
stuff, even if the fetch won't happen for a while.

The same algorithm would be invoked at all reasonable URL entry points, so
it happens synchronously at the point where URLs enter into platform APIs.
 (For example, that means it should happen in xhr.open, not xhr.send, and
that .srcset should be pre-parsed on assignment rather than reparsed
whenever the environment changes so blob URLs in srcset are captured.)

This would also fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=21058,
because URLs would be resolved against <base href> synchronously.

There's some question about precisely where this algorithm would be
invoked, and I don't have a complete answer to that, but I think the
discussion in #17765 makes a good start at figuring this out.  I think any
possible solution to this problem (and related problems with
non-autorevoking blobs) will have this problem, so this isn't an issue
specific to this proposal.

-- 
Glenn Maynard