I accidentally clicked on "Set as Desktop Background" yesterday, then I cancelled out. This morning while examining the cycle collector graph, I noticed that the page that I had clicked on for Set as Desktop Background was still in memory. It appears to be kept alive via a node in the chrome://browser/content/setDesktopBackground.xul document. I'll try to reproduce this later today. If anybody else wants to try this, about:ccdump is probably the way to go ( https://addons.mozilla.org/en-us/firefox/addon/cycle-collector-analyzer/ ). Basically, go to a page, do set as desktop background, cancel out of it, then close the page. Go to about:memory and run some GCs and CCs, then see if the document for the page you closed is still around. Here's the start of the path if that is useful: 0x131da98b0 [nsGenericElement (XUL) command id='Tools:PrivateBrowsing' chrome://browser/content/setDesktopBackground.xul] --[[via hash] mListenerManager]-> 0x1398e9c80 [nsEventListenerManager] --[mListeners[i] mListener]-> 0x136db7a80 [nsJSEventListener] --[mScopeObject]-> 0x1208c7100 [JS Object (ChromeWindow)] ---> 0x15bac0240 [JS Object (Array)] ---> 0x12d228340 [JS Object (Proxy)] ---> 0x132ae2820 [JS Object (HTMLImageElement)] --[xpc_GetJSPrivate(obj)]-> 0x12ed5a510 [XPCWrappedNative (HTMLImageElement)] From there, it connects to an img DOM node, and from there it leaks the entire page, it looks like. It isn't just that one element of the setDesktopBackground document, there are many other ones that are being held alive somehow: 0x1352c67d0 [nsGenericElement (XUL) menuitem id='historyRestoreLastSession' class='restoreLastSession' chrome://browser/content/setDesktopBackground.xul] 0x134fa9a10 [nsGenericElement (XUL) menu chrome://browser/content/setDesktopBackground.xul] 0x134dc60d0 [nsGenericElement (XUL) menu chrome://browser/content/setDesktopBackground.xul] The references to the XUL document itself are all accounted for, so it is just some elements of it that are being held alive somehow.
Summary: set desktop background image leaks the world → set desktop background image leaks the page
I'm not able to reproduce the leak with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120308 Firefox/13.0a1 even if I cancel the desktop background or I validate it. Maybe it depends on the platform.
I think I managed to reproduce it. I did something like this: 1) Go to a Huffington Post article with an image gallery. I went to this one: http://www.huffingtonpost.com/2012/04/12/newt-gingrich-fox-news-bias-cnn-romney_n_1420274.html 2) Scroll down to the image gallery near the bottom, click on "Fullscreen". This doesn't actually make it "full screen", it just goes to a regular full browser window image gallery. 3) Right click on the large image, click on "Set as desktop background image". Don't select anything on the dialogue that pops up. 4) Close the HuffingtonPost tab. 5) Close the background image dialogue window. 6) huffingtonpost.com still shows up in about:compartments
It's step #5 before #4. ;) Anyway I think it's an issue with one of your add-ons. I tried in safe mode and there is no zombie compartment or ghost window. In my case, I tried with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120412 Firefox/14.0a1 and the culprit add-on seeems to be Enter Selects 7 (https://addons.mozilla.org/en-US/firefox/addon/enter-selects/) └──────7,200 B (00.01%) -- top(none) │ ├──5,824 B (00.01%) -- ghost │ │ ├──2,240 B (00.00%) -- window(http://www.huffingtonpost.com/2012/04/12/newt-gingrich-fox-news-bias-cnn-romney_n_1420274.html) │ │ │ └──2,240 B (00.00%) ── dom  │ │ ├────896 B (00.00%) -- window(http://cdn.at.atwola.com/_media/uac/tcode3.html#&vert=Media&tags=kventryid=1420274;kvcmsid=hpo:1420274;kvent=3512447:3634781:3888333:4240727:3691656:3450960:3588411;kvsubj=982065:981465:980926:4944927:981525:981523;kvpagetype=bpage:news:slideshow:atf;kveditags=fox-news:newt-gingrich:fox-news-2012:media-and-the-elections:newt-gingrich-fox-nes-bias:newt-gingrich-fox-news;kvvert=media;kvblogger=jack-mirkinson;kvspon=y;) │ │ │ └──896 B (00.00%) ── dom  │ │ ├────896 B (00.00%) -- window(https://plusone.google.com/_/+1/fastbutton?url=http%3A%2F%2Fwww.huffingtonpost.com%2Fmedia&size=medium&count=true&width=450&annotation=none&hl=en-US&jsh=m%3B%2F_%2Fapps-static%2F_%2Fjs%2Fgapi%2F__features__%2Frt%3Dj%2Fver%3D4ZdqVor1c68.fr.%2Fsv%3D1%2Fam%3D!-SXmuOx1_3GIepEFVA%2Fd%3D1%2Frs%3DAItRSTNm-pO4B6Nvd9BDinUaTUx8AWxeBQ#id=I1_1334251013261&parent=http%3A%2F%2Fwww.huffingtonpost.com&rpctoken=358636710&_methods=onPlusOne%2C_ready%2C_close%2C_open%2C_resizeMe%2C_renderstart) │ │ │ └──896 B (00.00%) ── dom  │ │ ├────896 B (00.00%) -- window(http://cdn.at.atwola.com/_media/uac/tcodeqt.html#qc) │ │ │ └──896 B (00.00%) ── dom  │ │ └────896 B (00.00%) -- window(https://plusone.google.com/_/+1/fastbutton?url=http%3A%2F%2Fwww.huffingtonpost.com%2F2012%2F04%2F12%2Fnewt-gingrich-fox-news-bias-cnn-romney_n_1420274.html&size=tall&count=true&hl=en-US&jsh=m%3B%2F_%2Fapps-static%2F_%2Fjs%2Fgapi%2F__features__%2Frt%3Dj%2Fver%3D4ZdqVor1c68.fr.%2Fsv%3D1%2Fam%3D!-SXmuOx1_3GIepEFVA%2Fd%3D1%2Frs%3DAItRSTNm-pO4B6Nvd9BDinUaTUx8AWxeBQ#id=I2_1334251019068&parent=http%3A%2F%2Fwww.huffingtonpost.com&rpctoken=571145227&_methods=onPlusOne%2C_ready%2C_close%2C_open%2C_resizeMe%2C_renderstart) │ │ └──896 B (00.00%) ── dom  What's your add-on list, please?
No, I actually did close the tab before I closed the background image dialogue window. I could believe that that would cause problems. We had a similar problem with the find dialogue. I have Flashblock, Mass Password Reset, about:cc. I'll try reproducing on a clean profile now.
I was able to reproduce this using the steps in Comment 2 on a clean profile without any addons.
Which build? In safe mode?
Recent nightly, not safe mode. Did you try closing the tab before you close the background image dialogue window?
I reproduced in safe mode, too.
If it matters, I waited a few steps between 4 and 5.
Seconds, not steps. Sorry for the bugspam here...
I can't close the dialog box before the tab, Firefox refuses it.
Argh, I wanted to say "after": close the dialog box THEN the the tab.
Weird. You are on windows? Maybe this is a Mac specific problem. Not letting the underlying tab be closed out from under the background image dialogue seems like a reasonable solution.
Yes, I'm on Win 7: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120412 Firefox/14.0a1 Anyway I'll fill a bug because the add-on Enter Selects 7 creates zombie compartments with your STR. When I disable it (it's restartless), the zombie compartments just go away.
I can reproduce this on a OS X Nightly from a few days ago, but not on my current build (which includes the patch for bug 695480, which the Nightly did not). Do we still want to fix things like this?
Yeah, the leak was fixed by bug 695480. We can mark this WORKSFORME if you'd like. When I tried this before, the behavior was a little wonky with bug 695480 if you did the steps in Comment 2, because it can't actually set the desktop background any more, so if you try, the button just becomes greyed out. I don't know if you want to fix that or not, from a frontend perspective.
(In reply to Andrew McCreight [:mccr8] from comment #4) > No, I actually did close the tab before I closed the background image > dialogue window. On Windows this doesn't seem to be possible. The dialog is modal.
I can't reproduced even on a pre-695480 dev build. (But I could reproduce it with the "Enter Selects 7" add-on installed.) Combine this with comment 15 and comment 16 --> WORKSFORME.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.