title: Locating detached DOM tree memory leak
body: <p>I'm having trouble diagnosing a detached DOM tree memory leak in a very large single-page web app built primarily with Knockout.</p>
  
  <p>I've tweaked the app to attach a dummy <code>FooBar</code> object to a particular HTML button element which should be garbage collected as the user moves to a different "page" of the app.  Using Chrome's <em>heap snapshot</em> function, I can see that an old <code>FooBar</code> instance (which should have been GC'ed) is still reachable from its <code>HTMLButtonElement</code> in a (large) detached DOM tree.</p>
  
  <p>Tracing the references via the <em>retaining tree</em> panel, I follow the chain taking decreasing distance from the GC root.  However, <strong>at some point my search reaches a dead end at a node distance 4 from the root</strong> (in this case)!  The retaining tree reports no references to this node at all, yet somehow knows it is four steps from the GC root.</p>
  
  <p>Here is the part of the retaining tree which has me puzzled (the numbers on the right are distances from the root):</p>
  
  <pre><code>v foobar in HTMLButtonElement                                  10
    v [4928] in Detached DOM tree / 5643 entries                  9
      v native in HTMLOptionElement                               8
        v [0] in Array                                            7
          v mappedNodes                                           6
            v [870] in Array                                      5
              v itemsToProcess in system / Context                4
                  context in function itemMovedOrRetained()
                  context in function callCallback()
  </code></pre>
  
  <p>The retaining tree doesn't show the references here at distance 3 or above.</p>
  
  <p>Can anyone explain this to me?  I was hoping I'd be able to follow the reference chain back up to the offending part of the JavaScript app code -- but this has my stymied!</p>