set desktop background image leaks the page




7 years ago
7 years ago


(Reporter: mccr8, Unassigned)


(Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [MemShrink:P3])



7 years ago
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.


7 years ago
Summary: set desktop background image leaks the world → set desktop background image leaks the page

Comment 1

7 years ago
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.
Priority: -- → P3


7 years ago
Whiteboard: [MemShrink] → [MemShrink:P3]


7 years ago
Priority: P3 → --

Comment 2

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
I was able to reproduce this using the steps in Comment 2 on a clean profile without any addons.

Comment 6

7 years ago
Which build? In safe mode?

Comment 7

7 years ago
Recent nightly, not safe mode.  Did you try closing the tab before you close the background image dialogue window?

Comment 8

7 years ago
I reproduced in safe mode, too.

Comment 9

7 years ago
If it matters, I waited a few steps between 4 and 5.

Comment 10

7 years ago
Seconds, not steps.  Sorry for the bugspam here...

Comment 11

7 years ago
I can't close the dialog box before the tab, Firefox refuses it.

Comment 12

7 years ago
Argh, I wanted to say "after": close the dialog box THEN the the tab.

Comment 13

7 years ago
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

7 years ago
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?

Comment 16

7 years ago
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.
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.