As far as I know AngularJs .on does not support namespaces. https://docs.angularjs.org/api/ng/function/angular.element

Damn that sucks. The problem is that the only other way not to unbind globally is to unbind providing the bound function. But this is more constraining and not always possible!

Still this is a problem since it brokers other plugins, such as Highcharts.

Moreover, there are memory leak issues due to other listeners that are not unbound on scope destroy (a recent commit added unbindings on document destroy but some events are missing and document is not enough since we are doing SPA). I was planning to do a PR but it uses namespacing...

@ValentinH with 703ad38 I have changed the way the binding / unbinding work. Can you take a look if the memory leak problem has been solved?

I just made a test with that last version and I still have leaks problems. I'm checking what is missing compared to the modifications I made to fix them and I'll submit a PR.

I found the issue, it is the unbinding on the window that misses an argument.

angular.element($window).off(calcDimFn);

should be replaced by

angular.element($window).off('resize', calcDimFn);

Another remark: regarding the memory leaks issues, my tests have shown that the only important
unbindings are the one on document and window. So in my opinion, the code for the destroy event should simply be:

this.scope.$on('$destroy', function() {
    angular.element($window).off('resize', calcDimFn);
});

Indeed, the binding on the scope and on the element (and its children) of the directive are managed by angular: http://stackoverflow.com/questions/26983696/angularjs-does-destroy-remove-event-listeners

[Edit]: I have also read in several places that ensuring ourselves the unbinding was a good practice to prevent any bug. Indeed, in some rare cases, Angular might misses some unbinding so doing that ourselves is safer.

The weird thing is when I do two JS Heap snapshots in Chrome i see that the memory used is still increased.

What is your test scenario?

Mine was to navigate between two views, A and B where A contains a slider. Once on B, the all scope of A was still in memory in the previous version due to the leaks in angular-slider. Now, the A scope is correctly deleted when navigating to B.

Using Chrome

1. Load the demo site
2. Take heap snapshot
3. Play with slider handles for a few seconds
4. Wait 2 - 3 seconds
5. Take heap snapshot and compare to first one

Yeap I just tried this scenario and there are a few elements that are created during the sliders manipulation but nothing important in my opinion.

If you take 3 snapshots and check the objects that are still in Snap 3 but created between 1 and 2, there are nothing big. More importantly, I don't see any DOM Element that are still here because attached to a Scope object. So, it is OK AFAIK.

In my application, before you fix the leaks, all the scope object was kept between each view so after a lot of page views the application was containing something like a hundred scopes in memory. Now it is fixed.

[Edit]: I have also read in several places that ensuring ourselves the unbinding was a good practice to prevent any bug. Indeed, in some rare cases, Angular might misses some unbinding so doing that ourselves is safer.

@ValentinH, would you mind showing some example that angular misses some unbindings

Nope I don't. As I said it is only good practice, and use the term "might"... I don't have proof but it doesn't cost much to do it ourselves...

Yeah, i get it.
However, IMHO, part of the good coding style is to keep the code clean and do the necessary thing. Since we develop something based on angular which itself does a great job most of time, and there is no evidence of that problem/bug, we don't need to do that. Even if the bug exists, we should make an issue to angular, and we can do some hack/dirty work temporarily. Once the issue is fixed, we ought to go on the right way.
ehhh, just my opinion.

Are you talking about these unbindings: https://github.com/rzajac/angularjs-slider/blob/master/rzslider.js#L355-L358 .

I can retest the leaks when removing them on Monday but I think they were necessary...

https://github.com/rzajac/angularjs-slider/blob/master/rzslider.js#L325-L361
Nope, i'm taking about the deRegFuns and the unRegFn, what you have mentioned above of course they are necessary 'cause they won't be unbinded automatically

Oh I see, my comment was only referring to DOM event actually and the lines in my previous comment should be useless since this DOM element are created as children of the Directive and so will be deleted... I agree about the unbinding of watches, they are probably useless.