IE frees blob urls

Question

I have two audio files which have to be played one after the other. In order to do this, I downloaded the two files using XHR

var xhr = new XMLHttpRequest();
xhr.open('GET', fileURL, true);
xhr.responseType = 'arraybuffer';

xhr.onload = function () {
  data = new Uint8Array(xhr.response);
  //... other handling code
};

and constructed a Blob from them

var blob = new Blob([data], {type: 'video/mp4'})

These I used to construct Blob URLs

var url = URL.createObjectURL(blob)

which are then injected into <audio> tags. (audioDOM.src = url;)

This procedure works in Chrome and Firefox. However IE11 sometimes gives me a problem, it displays following notice:

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.

However, the weirdest part is that it does work (in IE) for the first file, but not for the second one. They both use the same code for the entire procedure, which is simply called using a different fileURL. Both files exist, are downloaded properly and have been logged to console for verification.

I attempted copying the data before constructing the blobs, but it does not seem to matter: the error remains.

Does anyone have an idea what causes the problem and how it could be fixed?

EDIT after sbgoran: The entire script runs on a single document, which is not being reloaded. I am still confused why it is the case. I did manage to create a workaround by looping and creating a new URL when the audio fails to load, but this is not a workable solution. The weird part is that the method described above fails at random: sometimes the URL is available when loaded into the <audio> tag, sometimes it isn't.

Answer 1

Apart from sbgoran's answer, I have another possible cause - as discussed on WhatWG mailing list, there's a bug in IE that causes a Blob to be garbage collected when the variable that points to it goes out of scope - even when there are still object URLs pointing to the Blob that haven't been revoked.

A workaround could rely on holding on to the original Blob object in a variable as long as the object URL is needed, then nullifying the variable and revoking its object URL afterwards.

Answer 2

Based on Remarks section of MSDN createObjectURL method page it could be plenty of things that IE might complain about. I'm not sure if you read this MSDN page before but maybe it can help in some way.

I would especially check note about blob urls origin policy

Blob urls are subject to an origin policy. This means that they can only be used in documents that have the same site-of-origin as the document running the script that created the url. If you need to use the blob object from an that is running in a different domain, you must use the postMessage API to send the blob data to the frame and then create the blob: url there.

and

URL returned by createObjectURL is valid for the lifetime of the creating document,