898728 - Blob URIs are briefly reusable after page unload, seemingly contradicting the FileAPI

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[swhitemanlistens-software]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20130518 Firefox/20.0 PaleMoon/20.1 (Nightly/Aurora)
Build ID: 20130518142809

Steps to reproduce:

Using an <INPUT type=file>, browse for an image.  
Use getObjectURL to retrieve the Blob URI.
Set the src of an IMG on the page to the Blob URI.
Copy the Blob URI to my keyboard.
Refresh the tab (note page is not fetched from cache).
Set the src of an IMG on the page to the copied Blob URI.

Testbed @ http://jsfiddle.net/sDj67/6/show/light/


Actual results:

The first attempt to set the src after the refresh succeeds, updating the IMG with the original saved bitmap.  

After some iterations of settting the src to an empty string and then setting back to the same Blob UTI, it will eventually fail to render the image, and from that point forward will no longer render the image, including after subsequent refreshes.




Expected results:

The URI should not be useable after a refresh, for any period of time.  A refresh fires the onunload event, that seems well, explicitly contrary to "This Blob URI must
persist... till the unloading document cleanup steps are executed."
[FileAPI spec 12.8.1.2.B] 

Even if the first document's unload is technically still "executing" in the background, it is definitely the intent of the spec that you are not supposed to be able to reuse a Blob URI from one DOM document when there is a new DOM document in its place.

[It is my guess -- just a guess -- that the URI is "lazy-revoked," like lazily closing a Websocket, but it shouldn't be reusable from another document even if the actual memory release is happening in the background.]

Comment 1

[Loic]

I'm not able to reproduce the issue, after the refresh, the fieled "Set Image Src to" keeps the Blob URI but doesn't display the image. Even if I paste the blob URI, it stays blank.

Could you update to Firefox 22 and test again, please?

Comment 2

[swhitemanlistens-software]

Same results on Firefox 22.

Make sure you're _changing_ the `Set Image Src` field (it has an onchange event).  So you can set it to blank or gibberish and then set to it to the Blob URI.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

From code inspection it looks like we revoke the URLs only after the document is GCd, not when we unload the document.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can you confirm that if you have about:memory open in a second tab the URL generally works before clicking "Minimize Memory" but never after?

Comment 5

[swhitemanlistens-software]

Yes, I confirm that `Minimize Memory Usage` prevents the tests from succeeding thereafter.

[FYI: this discovery came after a fellow dev reported to me that Mobile Safari (and Chrome Mobile, as we later noted) both persist the Blob URI *indefinitely* after unlimited refreshes. That is, where FF is unpredictable based on the GC timer but eventually settles down, those browsers are predictable, and always wrong.  IE 10 appears to have a correct implementation as the Blob URI never works at all after a refresh.]

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Thanks.  Should be a pretty easy fix.  I'll look at it on Monday.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

So, I was wrong, this turned out to be quite hard and I never did it :)  I think baku looked into something similar recently.

Comment 8

[Andrea Marchesini [:baku]]

Attachment: blob.patch

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f07eb53ea2ba
Blob should be invalidated when the window is destroyed, r=smaug

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f07eb53ea2ba