Step to reproduce: - Open firefox without any addon, without opening any page - right click on navigation toolbar > customize toolbar - close the customization dialog Now look at CC objects, you will see a long list FragmentOrElements objects. But only 3 of them are actually not owned by any other fragments of this list: menu_closeWindow, menu_showAllTabs and menu_close. (i.e. all others are children of these 3 or there is somehow some (in)direct edges to them from these 3 root objects) So far, it isn't really clear if we are actually leaking or if it's a CC optmization flaw.

I have some new data about this: These fragments have an indirect JSObject owner and seems to be the top level chrome window. Here is the list of edges from this chrome window to one fragment $(classname).$(attribute-name) JS Object (ChromeWindow).xpc_GetJSPrivate(obj) XPCWrappedNative (ChromeWindow).mIdentity nsGlobalWindow #4.mDocns Document normal (XUL) chrome://browser/content/browser.xul.mTemplateBuilderTable key FragmentOrElement (XUL) menu id='charsetMenu' chrome://browser/content/browser.xul.[via binding manager] mInsertionParentTable value FragmentOrElement (XUL) arrowscrollbox class='popup-internal-box' chrome://browser/content/browser.xul.[via binding manager] mContentListTable value nsAnonymousContentList.mElements->ElementAt(i) nsXBLInsertionPoint.mElements[i] FragmentOrElement (XUL) menu id='viewToolbarsMenu' chrome://browser/content/browser.xul.GetParent() FragmentOrElement (XUL) menupopup id='menu_viewPopup' chrome://browser/content/browser.xul.GetParent() FragmentOrElement (XUL) menu id='view-menu' chrome://browser/content/browser.xul.GetParent() FragmentOrElement (XUL) menubar id='main-menubar' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) menu id='tools-menu' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) menupopup id='menu_ToolsPopup' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) menu id='menu_socialAmbientMenu' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) menupopup id='menu_social-statusarea-popup' chrome://browser/content/browser.xul.mAttrsAndChildren[i] If you are on windows or linux and are interested in looking into this, I'm uploading the addon I'm using to get such data. (Open devtool toolbox, select mem panel and click on CC list. Then the list of all JS Object that (in)directly owns a suspicous fragment appear in the gray side menu list. (it stay empty if it can't find any fragment or no linked jsobject)) smaug, this xpi is different from the one I sent to you, CC list now displays JS OBject that owns a fragment.

I think I would currently call this a missing CC optimization. (it can be hard to define what is missing optimization or a leak.) I haven't figured out any super fast way to optimize out those elements from the graph. I'll try to look at this next week.

Here is a similar trace, but after some more GC cycles: JS Object (ChromeWindow).gNavToolbox JS Object (XULElement).palette JS Object (XULElement).UnwrapDOMObject(obj) FragmentOrElement (XUL) toolbarpalette id='BrowserToolbarPalette' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) toolbaritem id='personal-bookmarks' chrome://browser/content/browser.xul.mAttrsAndChildren[i] FragmentOrElement (XUL) hbox id='PlacesToolbar' chrome://browser/content/browser.xul.mAttrsAndChildren[i] This one is really interesting, as it highlights this code: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/toolbar.xml#176 So #BrowserToolbarPalette is removed from the DOM and kept in gNavToolbox.palette. I'm not sure that this is a leak? Could we have some confirmation from someone used to work with customization dialog?