On 09/17/2013 06:09 PM, Fernando Jiménez Moreno wrote:
Thanks for the prompt feedback, Olli!
On 17/09/2013, at 13:25, smaug wrote:
My proposal to change this is to add strong referenced message listeners in
these cases. I would say that we could add strong references by
default for all message listeners added via initDOMRequestHelper() during the
window init process
We need to still make sure we then remove those listeners at some point, unless
it is ok to keep the objects alive as long as the message manager
is alive.
Well, we will be observing "inner-window-destroyed" in DOMRequestHelper to
remove the associated listeners when the window is destroyed, but if I
am not wrong the message manager is associated with the window (is that
correct?), so yes, I guess the listeners should live as long as the message
manager lives.
Well, there are several types of message managers.
http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIMessageManager.idl
I belive we're talking here child side of frame and process message managers.
Process message managers aren't in anyway associated with any window
and frame message managers do have .content pointing to the top level window in
the frame scripts.
But if a new document is loaded, you get inner-window-destroyed for the
previous document/window.
, if we finally do what I proposed in 1.
Summary: - We need to add message listeners only when they are actually needed. - For
"one-shot" messages associated with specific requests,
we should add weak message listeners. - For messages that should be listened
during the lifetime of the window, we should add strong message
listeners.
....or keep the listeners alive by some other mechanism. Like adding some
expando property to the relevant window and keep listeners alive
there.
Is that something that is already possible or planned?
Well, hueyfix (https://bugzilla.mozilla.org/show_bug.cgi?id=695480) made us
automatically break certain
content<->chrome references when the content window goes away, but khuey or
bholley would need to verify if that applies to this case too.
-Olli
Thanks!
/ Fernando
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
