Re: createBlobURL

On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> The only real solution here is to abandon the use of URLs-strings
>> ("blob:...") and instead use some type of object which represents a
>> reference to the blob/stream/whatever. Then make img.src, iframe.src,
>> CSSStyleDeclaration.backgroundImage etc accept this new type in
>> addition to a string.
>
> If that is the only real solution I suggest we do that. We can create some
> kind of DOMURL type which is either a DOMString or a URL/Blob/something and
> change the relevant APIs.

This means that you can't use File objects together with things like
.innerHTML (neither the getter nor setter) or things like
CSSStyleDeclaration.background. Actually, it doesn't even work with
CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
And with the CSS Image Values spec [1] it can be something much more
complex.

If we don't want to use blob-URLs at all, we have to track down every
single DOM property which deals with URLs and:

A. Make sure that it doesn't use strings where URLs is part of the
string (like .innerHTML or CSSStyleDeclaration.background). If it
does, create a new object model that breaks down the string into
components where the URL is a separate component.
B. Make it take a DOMURL instead of a DOMString

While I agree that memory management is a horrible thing to thrust
upon developers, I really don't see an option here. It would
complicate matters hugely in cases like
CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
what the object model would look like which would work for [1]?

And as stated before, I think a hugely mitigating factor here is that
the amount of memory leaked is very small.

What I think we should do is to fine the places where people are most
likely to use blob-urls and in those cases change DOMString to DOMURL.
Such as HTMLImageElement.src like Darin proposes. But for the
remaining places keep createObjectURL/revokeObjectURL. I would imagine
that by just fixing a handful of properties we can cover 95% of the
use cases and make those not require the author to do memory
management.

[1] http://dev.w3.org/csswg/css3-images/

/ Jonas

Received on Thursday, 21 October 2010 17:55:49 UTC