From https://bugzilla.mozilla.org/show_bug.cgi?id=465269#c38: > The greater confusion and concern is that the code in the event notifications > that checks if "this._menu._teardown" exists pretty much fails all the time > and it seems like a great mystery to me as to why it is happening. dumps > (removed in the patch) suggest that this._menu._teardown is valid when it is > registered as a listener, and a dump in the notification suggests that we are > dealing with the same XUL object and wrapper (as this._menu) when the > notification actually fires. > > I think we may have some other kind of listener leak on our hands, which is > not terribly surprising given the mysterious disappearance of _teardown. > Unfortunately, I may have caused this as a result of debugging code as I had > accidentally removed one of the calls to removelistener. I guess, just keep > an eye out for this. The only real good way to keep an eye on this is to > break on "nsMsgMailSession::AddFolderListener" and take a look > "*mListeners.mArray.mHdr" while you are in there. You can compel the widget > to be instantiated by right-click and choosing to add a new folder. The new > folder dialog uses the widget. It is safer than using the folder-picker > combobox, at least on linux, because GrabKeys happens for popups and then > your X session becomes useless. > > I don't think the last 2 probably are immediately addressable, and they > certainly are not new, but if you have any ideas, I'd be glad to hear them. > Otherwise they too should probably get a bug. And so here's the bug for them. Some more info: The calls are in mailnews/base/content/folderWidgets.xml, in <field name="_listener">'s OnItemAdded and OnItemRemoved methods. Thanks, Blake.

We should check if this is still happening. The folder picker code still does check if this._menu._teardown exists.