Re: Blob URLs | autoRevoke, defaults, and resolutions

On Sun, May 5, 2013 at 7:37 PM, Jonas Sicking <> wrote:

> What we do is that we
> 1. Resolve the URL against the current base URL
> 2. Perform some security checks
> 3. Kick off a network fetch
> 4. Return
> Note that no actual network activity happens here. That is all being
> done on background threads. But what we do in step 3 is to send the
> signal to the network code that it should start doing all the stuff
> that it needs to do.
> Step 3 is where we inserted the code to grab a reference to the Blob
> such that it doesn't matter if the URL is revoked.
> Some of this code will change. For example I'd like to move towards
> doing the security checks asynchronously. Essentially by making them
> part of the "the stuff that the network code needs to do". But I we'll
> always need to fire off that algorithm from the main thread, and
> generally doing that synchronously is the simplest solution.

I think the only difference between this and what I'm suggesting is that
grabbing the blob happens in step #1, instead of step #3.  That way, it
still works if the fetch isn't actually started right away (srcset,
on-demand image loading,, etc).

Glenn Maynard

Received on Monday, 6 May 2013 01:26:01 UTC