Re: Blob URLs | autoRevoke, defaults, and resolutions

Eric,


On May 1, 2013, at 7:25 PM, Eric U wrote:

> On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 
>> 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].
> 
> Ugly.
> 
>> This could mean that the "blob" clause for "basic fetch"[5] only defines some cases where a synchronous fetch can be run (TBD) but expressly disallows others where synchronous fetching is not feasible.  This would limit the use of Blob URLs pretty drastically, but might be the only solution.  For instance, asynchronous calls accompanying <embed>, "defer" etc. might have to be expressly disallowed.  It would be great if we do this in fetch [5] :-)
> 
> Just to be clear, this would limit the use of *autoRevoke* Blob URLs,
> not all Blob URLs, yes?


In fact, Glenn has me convinced that this will actually affect ALL Blob URLs.  I can't see a way around that.  In this case, autoRevoke does the right thing with respect to revoking URLs, but the same restrictions apply to manual revoke as well, since it is possible to create concurrent revocations with manual revoke.


> 
>> Essentially, this might be to "do what Firefox does" but document what "dereference" means [6], and be clear about what might break.  Most implementors acknowledge that use of Blob URLs simply won't work in some cases (e.g. CSS cases, etc.).  We should formalize that; it would involve listing what works explicitly.  Anne?
>> 
>> 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 :)
> 
> I'm not really sure this is so bad.  I know it's the case I brought
> up, and I must admit that I disliked the "oneTimeOnly" when I first
> heard about it, but all other proposals [including not having
> automatic revocation at all] now seem worse.  Here you've set
> something to be oneTimeOnly and used it twice; if that fails in IE,
> that's correct.  If it works some of the time in other browsers [after
> they implement oneTimeOnly], that's not good, but you did pretty much
> aim at your own foot.  Developers that actively try to do the right
> thing will have consistent good results without extra code, at least.
> I realize that img1.src = img2.src failing is odd, but as [IIRC]
> Adrian pointed out, if it's an uncacheable image on a server that's
> gone away, couldn't that already happen, depending on your network
> stack implementation?


Well, that's why I documented it as a possible solution, but didn't document not having automatic revocation at all :)  Yes, Adrian's example serves to illustrate that this *could* already happen, depending on network stack.  But in the case of a file reference, this probably shouldn't happen.

-- A*