On 27/07/2013 2:53 AM, Justin Lebar wrote:
...
>
Whether or not we totally succeed in this endeavor is another question
entirely. You could instrument your build to count the number of live
nsFrameMessageManager objects and report the number of message
listeners in each -- one way to do this would be with a patch very
similar to this one [1].
Thanks for following up. I'll add some hacks to count the message
listeners as you suggest and followup here with what I find.
Just to be clear though, if I find they are *not* all being removed, I
should open a bug on that rather than just removing the listeners myself
and calling it done? ie, is it accurate to say that it *should* not be
necessary to remove these handlers (and, if I verify that is true, that
I could explicitly add a note to this effect on the relevant MDN pages?)
Thanks,
Mark
[1] https://bug893242.bugzilla.mozilla.org/attachment.cgi?id=774978
On Thu, Jul 25, 2013 at 6:51 PM, Mark Hammond <mhamm...@skippinet.com.au> wrote:
Felipe and I were having a discussion around a patch that uses
nsIMessageManager. Specifically, we create a <browser> element, then call
browser.messageManager.addMessageListener() with the requirement that the
listener live for as long as the browser element itself.
The question we had was whether it was necessary to explicitly call
removeMessageListener, or whether we can rely on automatic cleanup when the
browser element dies? It seems obvious to us that it *should* be safe to
rely on automatic cleanup, but searching both docs and mxr didn't make it
clear, so I figured it was better to ask rather than to cargo-cult the
addition of explicit cleanup code that wasn't necessary.
Thanks,
Mark
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
