mozilla

Compare Revisions

Common causes of memory leaks in extensions

Change Revisions

Revision 235078:

Revision 235078 by kmaglione on

Revision 49903:

Revision 49903 by Nmaier on

Title:
Common causes of memory leaks in extensions
Common causes of memory leaks in extensions
Slug:
Extensions/Common_causes_of_memory_leaks_in_extensions
Extensions/Common_causes_of_memory_leaks_in_extensions
Tags:
Extensions, Add-ons, memory
Extensions, Add-ons, memory
Content:

Revision 235078
Revision 49903
n10    <h2>n10    <h2 id="Causes_of_zombie_compartments">
n16    <h3>n16    <h3 id="Storing_references_to_window_objects_and_DOM_nodes">
n60    <h3>n60    <p>
61      <br>
62      To avoid these issues, references to DOM nodes in foreign d
 >ocument should instead be stored in an object which is specific t
 >o that document, and cleaned up when the document is unloaded, or
 > stored as <a href="/en/Components.utils.getWeakReference" title=
 >"/en/Components.utils.getWeakReference">weak references</a>.
63    </p>
64    <h3 id="Be_careful_with_setInterval/setTimeout">
n81      If your add-on makes use of long-lived timeouts or uses {{ n85      Instead, when your timeouts or intervals are tied to a cont
>domxref("window.setInterval()") }}, you need to take special care>ent window, the the timeout should be added via that window inste
> to ensure your code won't accidentally leak content windows. The>ad. For instance, rather than <code>window.setInterval(function (
>refore, your add-on should clean up such intervals and timeouts w>) { doSomethingWith(content.document.title) }, 1000)</code>, one 
>hen the corresponding content document is unloaded, by adding an >should use <code>content.setTimeout(function () { doSomethingWith
><code>unload</code> event listener or by similar means. Another s>(content.document.title) }, 1000)</code>. Notably, this should <e
>olution would be to use the <code>setInterval()</code>/<code>setT>m>never</em> be done via <a href="/en/Safely_accessing_content_DO
>imeout()</code> instances content windows provide, but there is a>M_from_chrome">unwrapped content objects</a>.
> big drawback with this idea: If the user disables JavaScript glo 
>bally or locally (such as by using an add-on like NoScript), then 
> using the content window functions won't work. 
86    </p>
82    </p>87    <p>
88      If the above is not feasible, and your add-on makes use of 
 >long-lived timeouts or {{ domxref("window.setInterval()") }}, you
 > need to take special care to ensure your code won't accidentally
 > leak content windows. Therefore, your add-on should clean up suc
 >h intervals and timeouts when the corresponding content document 
 >is unloaded, by adding an <code>unload</code> event listener or b
 >y similar means.
83    <h3>89    </p>
90    <h3 id="Problems_in_bootstrapped_(restartless)_add-ons">
n112    <h3>n119    <h3 id="Failing_to_clean_up_event_listeners">
n138    <h2>n145    <h2 id="Causes_of_other_kinds_of_leaks">
n144    <h3>n151    <h3 id="Forgetting_to_unregister_observers">
n206    <h3>n213    <h3 id="Forgetting_to_unload_JavaScript_modules_in_restartles
 >s_add-ons">
t241    <h2>t248    <h2 id="Other_information">

Back to History