[whatwg] Assigning media resources represented as DOM objects to a media element

[Glenn Maynard]

On Sun, Feb 17, 2013 at 3:17 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

>  Ugh, can't we take turns with other browsers or draw straws or something?
> Or study existing code using createObjectURL to get some data first?
>

I don't know if you have any way of testing this in bulk, but once you have
the auto-revoke infrastructure in place, it's probably straightforward to
instrument non-auto-revoking blob URLs to see where they're actually used
after their initial top-level script stack has returned (eg. where this
change would be breaking).

cloneNode() won't work for autorevoked URLs, because it is defined to only
> clone attributes and children, not internal state (with a few exceptions
> for Web compatibility). (Don't tell me that it shouldn't work that way; I
> argued that long ago and lost :-).)


It may be worth raising the argument again, since we have additional
information now (this feature), though it's not high up on my list.


On Mon, Feb 18, 2013 at 3:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Sat, Feb 16, 2013 at 7:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > Since we have a real URL parser now, I think we have a reasonable way to
> do
> > this: capture the blob in the parser, returning it as part of the parsed
> > URL.
>
> Although this might theoretically work, I suspect it'll take a while
> before browsers get URL parsers that match the architecture of the
> specification. (They all have somewhat different architectures at the
> moment and trying to extend them in any meaningful manner at this
> point seems like asking for trouble.)
>

That's fine, since the main goal is to have a simple, consistent way of
making it clear in specs exactly when the blob of a blob URL is captured.
Whether that's actually implemented as part of the URL parser or at a
higher level is an implementation detail.

I suspect this will also fix some underdefined behavior with the
non-autorevoking blobs we have today.  For example:

    var url = URL.createObjectURL(blob);
    img.src = url;
    URL.revokeObjectURL(url);

I think according to spec this may or may not work, since "update the image
data" might or might not happen synchronously.  This actually does work in
Chrome and Firefox, so I'm guessing it wouldn't actually be web-compatible
to do that.  Capturing the blob when @src (and srcset) is assigned would
fix this, so the blob is captured synchronously even if the browser isn't
going to load the image right away.

-- 
Glenn Maynard