title: Javascript memory leaks: why would assigning object to null work?
body: <p>Can someone scratch an itch for me in regards to the nature of assignment-to-null fix used to prevent memory leaks?</p>
  
  <p>We are all familiar with the following technique to stop the circular reference between the DOM object and the JS object, in order to prevent memory leaks:</p>
  
  <pre><code>    function foo() {
        var ele = document.getElementById("someParagraphId");
  
        ele.onclick = function() {
          //some action here
        };
  
        ele = null;
      }
  </code></pre>
  
  <p>The question is why would the above work?  Setting "ele" to null will definitely stop the circular references, but wouldn't it also prevent future references to "ele"? </p>
  
  <pre><code>    function foo() {
        var ele = document.getElementById("someParagraphId");
  
            ele.onclick = function() {
                console.log("accessing ele ... after set to null " + ele.onclick);
            };
  
        ele = null;
  
      }
  </code></pre>
  
  <p>And yet the event listener fires.  It will complain that "ele" object is null (which is what we would expect).</p>
  
  <p>Given the above behavior, are we right to deduce that the Javascript engine implemention will hold some sort of internal reference to the event listener, and it is this reference that is called when the event is triggered?</p>
  
  <pre><code>eventHandlerRef = //assignment to "ele.onclick" handler/listener;
  </code></pre>
  
  <p>If there were to be a reference like the above, wouldn't the assignment-to-null fix be implementation dependent? Or, is it part of the ECMAScript specification.  </p>
  
  <p>From my understanding, this fix has always been cross browser safe.  I haven't come across many examples that makes specific mentions on detecting/sniffing the browser type before applying the null assignment.</p>
  
  <p><strong><em>===============EDIT==================</em></strong></p>
  
  <p>I think due to the way I've laid out the question may have unwittingly directly the discussion from what I was trying to convey.  A couple of concepts that are being referenced:</p>
  
  <p>object handles/object references ala:</p>
  
  <pre><code> var obj1, obj2;
       obj1 = {foo: "bar"}; //obj1 points to the an area of the heap allocated 
                            //for the object literal.
  
   obj2 = obj1;     //obj2 points to the same position in the heap
                        //as obj1.
  
   //obj1 = null or
   obj1 = {/*another obj literal*/}  //the new object literal is created 
                                         //and allocated in some other part 
                                         //in the heap, and obj1 now points 
                                         //to the new location.
  
  //obj2 is unaffected by obj1's re-assignment. 
  </code></pre>
  
  <p>The above isn't where my itch lies, and I regret adding the line:</p>
  
  <pre><code>console.log("accessing ele ... after set to null " + ele.onclick);
  </code></pre>
  
  <p>The above makes this look a closure question. I fully expected the error to be thrown as indicated in the original post.</p>
  
  <p>My itch is more along the context of ... for some reason, in my mind, I keep thinking that Javascript engine will call the <code>ele.onlick()</code> directly when the event fires and setting the element to null is akin to the following flow:</p>
  
  <pre><code>var obj = {};
  obj.method = function() {};
  
  obj = null;
  //error calling obj.method(), i.e., obj is null
  </code></pre>
  
  <p>Given that we know in the original post that the event handler still fires after ele has been set to null, in my mind the flow is more akin to:</p>
  
  <pre><code>var obj = {};
  obj.method = function() {};
  
  var objRef = obj; 
  
  obj = null;  
  
  //The Javascript Engine calling objRef.method when event triggered.
  </code></pre>
  
  <p>My itch comes down to the question, is the above how most Javascript implementation work, where some internal reference is pointing to the event handler assigned, and it is this internal reference is called when the event is triggered?</p>
  
  <p>Or phrased differently,  what is stopping a Javascript Engine implementation from calling <em>an</em> <code>ele.onclick()</code> directly (setting aside for the moment the design and architecture issues)?</p>
  
  <p>Maybe my thought processes works differently, but didn't anyone else take a second look when they encountered the assignment-to-null fix for the first time, where the element reference was null-ed and yet the code for the handler was still be executed?</p>