W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] IE10 inconsistency with Blob / createObjectURL

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 2 Feb 2014 14:37:39 -0800
Message-ID: <CA+c2ei9GDxC=-WibZ0QvxZ0zjtGLxtdCwH1k47UFb4+NDq=vgw@mail.gmail.com>
To: Katelyn Gadd <kg@luminance.org>
Cc: WHATWG <whatwg@lists.whatwg.org>
Yup, this seems like a bug in IE. Microsoft doesn't read this list
though, so I suggest contacting them directly.

You might also want to file a bug against the File spec to get the
spec to be even more explicit about the requirements here.

https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG

/ Jonas

On Fri, Jan 31, 2014 at 6:48 PM, K. Gadd <kg@luminance.org> wrote:
> Apologies if this has come up on the list before:
>
> IE10 appears to have shipped implementations of the Blob constructor along
> with createObjectURL. While they work, there appears to be a significant
> deviation from the spec behavior (at the very least, Firefox and Chrome
> implement these APIs as I'd expect).
>
> When a Blob gets GCed in IE10, it appears to intentionally destroy the
> object URL associated with it, instead of waiting for you to revoke the
> object URL. When this happens it spits out a vague console message:
>
> HTML7007: One or more blob URLs were revoked by closing the blob for which
> they were created. These URLs will no longer resolve as the data backing
> the URL has been freed.
>
> This is confusing because the API doesn't even have a way to 'close' blobs;
> all that is necessary to trigger this is to let a Blob get collected by
> going out of scope.
>
> From reading the spec I don't see any language that suggests this behavior
> is allowed or expected. I can try to work around it by retaining all the
> blobs but it seems unnecessary...
>
> -kg
Received on Sunday, 2 February 2014 22:38:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC