See bug 805246 comment 18. STR: 1) Enable social functionality, let it load 2) Check about:memory, notice three contentpanel.php functions (one corresponding to each notification button) 3) Disable the social functionality from the Tools menu 4) wait some time, run "minimize memory usage" in about:memory Expected: three contentpanel.php entries disappear Actual: they seem to stay around indefinitely SocialToolbar.updateButtonHiddenState removes the iframes from the DOM, so I'm not sure how this is happening. It's possible they're being leaked some other way?
Created attachment 677247 [details] [diff] [review] Patch updateButtonHiddenState is the function that is meant to remove the panels, but SocialUI.haveLoggedInUser() keep returning true even after the feature is turned off, because the profile is not cleared http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-social.js#704
Comment on attachment 677247 [details] [diff] [review] Patch I think this is fine, as if we have a code path which doesn't reach this on social being disabled we have bigger problems (eg, the worker is still running). Longer term I think we should set .provider to null, but that is risker for 17/18.
Comment on attachment 677247 [details] [diff] [review] Patch Actually, it possibly should be set to undefined? The difference between null and undefined will be if the "toolbar cache" is used on re-enabling the feature.
Created attachment 677250 [details] [diff] [review] Set profile to undefined
Comment on attachment 677247 [details] [diff] [review] Patch Ah, this makes sense. undefined as Mark suggests is the way to go, since that's the initial value before social is enabled.
Created attachment 677251 [details] [diff] [review] Set profile to undefined
Comment on attachment 677251 [details] [diff] [review] Set profile to undefined [Triage Comment] very simple "leak" fix, let's get this on aurora/beta
Hmm, not really related to this bug, but we should probably also be clearing ambientNotificationIcons, right?
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #9) > Hmm, not really related to this bug, but we should probably also be clearing > ambientNotificationIcons, right? yes, we should. I don't think the toolbars will be impacted (as it wants a profile before it uses them) but SocialMenu looks like it might still show them (it only looks at Social.active and doesn't take the lack of a profile into account)
Verified fixed using steps in comment 0.