Repeated elements get leaked if you remove some elements from the source list.

[Bringer128]

First off, thanks for this library, it's awesome!

JsFiddle example here: http://jsfiddle.net/bp0821bf/1/

It's easiest to see if you open up http://fiddle.jshell.net/bp0821bf/1/show/light/ (no iframes).

I tested this by using Chrome Developer Tools, taking a profiler snapshot and finding the detached HTMLSpanElements:

This causes a very minor leak in our production software.

[thgreasi]

Thanks for your detailed report. I will investigate it tonight.

[thgreasi]

I created a new branch to test for memory leaks but saw not difference with the master branch in my tests (on chrome 37 beta).

I think we should check for yellow nodes to find the origin of the variable that holds the reference (I tried to spot a leaked li). Moreover, I could find only two red nodes in my tests though (even after several sortings). While hovering around on the snapshot I was not able to spot any variable or closure from within ui-sortable.

Some extra notes:

• I found that the detached node count does not increase after the initial sorting. (Both in timeline and heap allocations views.)
  
• Two of the red detached nodes, seem to be the template ones, probably used by angular (I checked the innerText of the nodes).
  

Waiting for your response.

[Bringer128]

Thanks for your prompt resonse!

I was using Chrome 36 stable. Each time I run the example I get 3 or 4 'red' span nodes as per my screenshot above. I've filtered by 'detached' and added another one here:

The yellow path in the above screenshot appears to show JQuery holding a reference to HTMLLIElement that contains the <span>Two</span>.

With that said, I understand that this is an integration library and that the leaked nodes may be due to Angular, JQuery, JQueryUI or some combination of the 3. I'm happy to move on if we can rule out angular-ui-sortable as the cause.

Thanks :)

[thgreasi]

Ok, I just realized that didn't investigate enough the case that an item of the model is removed...
The reproducable use case I found is:

1. Move "tree" first
2. Mode "two" second"
3. Delete "tree"
4. Delete "two"
   

PR #244 seems to be fixing this, at least as of the detached red node issue.
I'm merging it since it seems logical and does not break any test and will wait for your feedback.