----- Original Message -----
> Why so?
>
> function f(e){}
>
> (function(){
> var iframe = document.getElementByTagName('iframe')[0];
> iframe.addEventListener('someEvent', f);
> })()
>
> In this case, f doesn't hold a reference to anything besides itself, not
> to the iframe at least. In the case of DOM events, it can look at its
> argument to find e.target which will dynamically (!), only for the time
> of the listener call, refer to the iframe.
>
> In any case, when an event doesn't need to be listened to anymore, there
> is a time in your application where you can remove the listener. The
> leak is not removing the listener, not the listener itself.
Well, you can look at the patch. I guess I described it poorly. You have some
thing (I said 'iframe' above, but I guess it isn't really one) x that wants to
listen to an event, so you create an event listener for it, that holds alive x.
The situation is more like this:
function f(e){tellSomebodyAboutTheEvent(x);}
(function(){
var iframe = document.getElementByTagName('iframe')[0];
iframe.addEventListener('someEvent', f);
})()
f is now keeping x alive, and if f is the only thing keeping x alive, then
that's basically a leak as far as we are concerned as a JS programmer.
(There's also the problem that f stays alive forever if the event never fires,
but that's a smaller leak...)
In case being concrete helps, in our case, x was the parent-process
representation of some app, and the event was some kind of visibility change
event, so you can tell the app if the screen is turned off or on. Obviously,
you want to get rid of x rather than keep it around to ensure that we can tell
this zombie app thing that the screen is going to turn off.
Andrew
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
