Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 5:36 PM, Arun Ranganathan <arun@mozilla.com> wrote:

> 2a. To meticulously special-case Blob URLs, per Bug 17765 [4].  This calls
> for a synchronous step attached to wherever URLs are used to "peg" Blob URL
> data at fetch, so that the chance of a concurrent revocation doesn't cause
> things to behave unpredictably.  Firefox does a variation of this with
> keeping channels open, but solving this bug interoperably is going to be
> very hard, and has to be done in different places across the platform.  And
> even within CSS.  This is hard to move forward with.
>
> 2b.To adopt an 80-20 rule, and only specify what happens for some cases
> that seem common, but expressly disallow other cases.  This might be a more
> muted version of Bug 17765, especially if it can't be done within fetch [5].
>

I'm okay with limiting this in cases where it's particularly hard to
define.  In particular, it seems like placing a hook in CSS in any
deterministic way is hard, at least today: from what I understand, the time
CSS parsing happens is unspecified.

However, we probably can't break non-autorevoke blob URLs with CSS.  So,
I'd propose:

- Start by defining that auto-revoke blob URLs may only be used with APIs
that explicitly capture the blob (putting aside the mechanics of how we do
that, for now).  Blob capture would still affect non-autorevoke blob URLs,
since it fixes race conditions, but an uncaptured blob URL would continue
to work with non-autorevoke URLs.
- Apply blob capture to one or two test cases.  I think XHR is a good place
for this, because it's easy to test, due to the xhr.open() and xhr.send()
split.  xhr.open() is where blob capture should happen, and xhr.send() is
where the fetch happens.
- Once people are comfortable with how it works, start applying it to other
major blob URL cases (eg. <img>).  Whether to apply it broadly to all APIs
next or not is something that could be decided at this point.

This will make autorevoke blob URLs work, gradually fix manual-revoke blob
URLs as a side-effect, and leave manual-revoke URLs unspecified but
functional for the remaining cases.  It also doesn't require us to dive in
head-first and try to apply this to every API on the platform all at once,
which nobody wants to do; it lets us test it out, then apply it to more
APIs at whatever pace makes sense.

(I don't know any way to deal with the CSS case.)



> 2c. Re-use oneTimeOnly as in IE's behavior for autoRevoke (but call it
> autoRevoke).  But we jettisoned this for race conditions e.g.
>
> // This is in IE only
>
> img2.src = URL.createObjectURL(fileBlob, {oneTimeOnly: true});
>
> // race now! then fail in IE only
> img1.src = img2.src;
>
> will fail in IE with oneTimeOnly.  It appears to fail reliably, but again,
> "dereference URL" may not be interoperable here.  This is probably not what
> we should do, but it was worth listing, since it carries the brute force of
> a shipping implementation, and shows how some % of the market has actively
> solved this problem :)
>

There are a lot of problems with oneTimeOnly.  It's very easy for the URL
to never actually be used, which results in a subtle and expensive blob
leak.  For example, this:

setInterval(function() {
    img.src = URL.createObjectURL(createBlob(), {oneTimeOnly: true});
}, 100);

might leak 10 blobs per second, since a browser that "obtains images on
demand" might not fetch the blob at all, while a browser that "obtains
images immediately" wouldn't.

-- 
Glenn Maynard