Last Comment Bug 734210 - set desktop background image leaks the page
: set desktop background image leaks the page
Product: Firefox
Classification: Client Software
Component: Shell Integration (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: leakychrome
  Show dependency treegraph
Reported: 2012-03-08 11:55 PST by Andrew McCreight [:mccr8]
Modified: 2012-05-09 01:46 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Andrew McCreight [:mccr8] 2012-03-08 11:55:52 PST
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 ( ).  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.
Comment 1 Loic 2012-03-08 16:54:37 PST
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.
Comment 2 Andrew McCreight [:mccr8] 2012-04-12 09:45:05 PDT
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:

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) still shows up in about:compartments
Comment 3 Loic 2012-04-12 10:30:36 PDT
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 (

└──────7,200 B (00.01%) -- top(none)
│          ├──5,824 B (00.01%) -- ghost
│          │  ├──2,240 B (00.00%) -- window(
│          │  │  └──2,240 B (00.00%) ── dom [5]
│          │  ├────896 B (00.00%) -- window(;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 [2]
│          │  ├────896 B (00.00%) -- window(!-SXmuOx1_3GIepEFVA%2Fd%3D1%2Frs%3DAItRSTNm-pO4B6Nvd9BDinUaTUx8AWxeBQ#id=I1_1334251013261&
│          │  │    └──896 B (00.00%) ── dom [2]
│          │  ├────896 B (00.00%) -- window(
│          │  │    └──896 B (00.00%) ── dom [2]
│          │  └────896 B (00.00%) -- window(!-SXmuOx1_3GIepEFVA%2Fd%3D1%2Frs%3DAItRSTNm-pO4B6Nvd9BDinUaTUx8AWxeBQ#id=I2_1334251019068&
│          │       └──896 B (00.00%) ── dom [2]

What's your add-on list, please?
Comment 4 Andrew McCreight [:mccr8] 2012-04-12 10:36:55 PDT
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.
Comment 5 Andrew McCreight [:mccr8] 2012-04-12 10:47:53 PDT
I was able to reproduce this using the steps in Comment 2 on a clean profile without any addons.
Comment 6 Loic 2012-04-12 10:51:29 PDT
Which build? In safe mode?
Comment 7 Andrew McCreight [:mccr8] 2012-04-12 10:52:57 PDT
Recent nightly, not safe mode.  Did you try closing the tab before you close the background image dialogue window?
Comment 8 Andrew McCreight [:mccr8] 2012-04-12 10:54:45 PDT
I reproduced in safe mode, too.
Comment 9 Andrew McCreight [:mccr8] 2012-04-12 10:55:10 PDT
If it matters, I waited a few steps between 4 and 5.
Comment 10 Andrew McCreight [:mccr8] 2012-04-12 10:55:26 PDT
Seconds, not steps.  Sorry for the bugspam here...
Comment 11 Loic 2012-04-12 10:56:57 PDT
I can't close the dialog box before the tab, Firefox refuses it.
Comment 12 Loic 2012-04-12 10:58:16 PDT
Argh, I wanted to say "after": close the dialog box THEN the the tab.
Comment 13 Andrew McCreight [:mccr8] 2012-04-12 11:04:12 PDT
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.
Comment 14 Loic 2012-04-12 11:07:10 PDT
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.
Comment 15 Justin Dolske [:Dolske] 2012-04-27 08:24:10 PDT
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?
Comment 16 Andrew McCreight [:mccr8] 2012-04-27 08:29:18 PDT
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.
Comment 17 Dão Gottwald [:dao] 2012-04-27 09:01:47 PDT
(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.
Comment 18 Nicholas Nethercote [:njn] 2012-05-02 21:34:01 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.