I have a GreaseMonkey script that works on a site that uses frames as an integral part of its interface. This script leaks memory like a sieve, and I believe it is due to m
Without seeing your complete script, or a Short, Self Contained, Compilable Example, we can't be sure of what is going on. It may be that addEventListener
is not the problem.
Here are some strategies for better code, with fewer memory leaks:
Inline/anonymous functions are often a culprit, especially with event handlers.
Poor / Leaky:
elem.onclick = function () {/*do something*/};
elem.addEventListener ("click", function() {/*do something*/}, false);
$("elem").click ( function () {/*do something*/} );
Not leaky and also easier to maintain:
elem.onclick = clickHandler;
elem.addEventListener ("click", clickHandler, false);
$("elem").click (clickHandler);
function clickHandler (evt) {
/*do something*/
}
Note that for userscripts you should avoid onclick, etc. anyway.
Likewise do not use JS on HTML attributes. EG don't use <span onclick="callSomeFunction()">
, etc.
Minimize the code that runs in iframes to only that code you explicitly want.
@include
, @exclude
, and @match
directives to block as many unwanted iframes as possible.Wrap all code that doesn't need to run in iframes in a block like so:
if (window.top === window.self) {
// Not in a frame
}
Do not use innerHTML
.
For lots of elements, or elements that come and go with AJAX, do not use addEventListener()
or jQuery's .bind()
, .click()
, etc.
This replicates the listener across, potentially, thousands of nodes.
Use jQuery's .on(). That way the listener is attached only once and triggers appropriately via bubbling. (Note that in some rare-ish cases .on()
can be blocked by the page's javascript.)
In your case, you probably want something like:
$(document).on ("click", "YOUR ELEM SELECTOR", clickHandler);
function clickHandler (evt) {
/*do something*/
}
To avoid surprise circular references or orphaned items, use jQuery to add or remove elements, rather than direct DOM methods like createElement()
, appendChild()
, etc.
jQuery is designed/tested to minimize such things.
Beware of overusing GM_setValue(). It easily can use lots of global resources or cause a script instance to crash.
localStorage
.GM_setValue()
to store anything but strings. For anything else, use a serializer such as GM_SuperValue. Even innocent looking integers can cause the default GM_setValue()
to crash.Always check return values and assume that elements can be missing:
This is poor (and, alas, typical):
$("selector").text($("selector").text().match(/foo=([bar]+)/)[1]);
Better:
var salesItemDiv = $("selector");
var fooMatch = salesItemDiv.text ().match (/\bfoo\s*=\s*([bar]+)\b/i);
if (fooMatch && fooMatch.length > 1) {
salesItemDiv.text ( fooMatch[1] );
}
possibly followed by:
salesItemDiv = fooMatch = null;
see below.
Beware of recursive / inline setTimeout()
calls. Use setInterval()
for repeated timing. Just like with event handlers, do not use inline/anonymous functions.
Run your code through JSLint.
Avoid eval()
and auto/hidden eval() invocations.
Set variables to null
when you are done with them. See this, for example.
Reference: "Do you know what may cause memory leaks in JavaScript?"
Additional reading on JS memory leaks
Mozilla Performance: Leak Tools