docs.angularjs.org: DOM Nodes Leaking

[chylvina]

At http://docs.angularjs.org, click back and forth between pages the DOM Node Count continues to go up and up. No dramtical drop when I click "collect garbage".

[chylvina]

I found many app built with angular has the same problem. Could someone provide some solution to fix this?

[caitp]

you might be able to help fix it by making sure that you unregister DOM and scope event handlers when possible (eg during scope '$destroy'). I expect ngRoute will $destroy $scope before compiling the new template.

But, I can't promise that this will work. :(

https://github.com/angular/angular.js/blob/master/src/ngRoute/directive/ngView.js#L188 scope cleanup in ngRoute, and https://github.com/angular-ui/ui-router/blob/master/src/viewDirective.js#L82 in ui-router. Unfortunately there's no real way to ensure that DOM event handlers get removed, though ._.

[petebacondarwin]

This does appear to be a valid concern, at least on Chrome.

[petebacondarwin]

It is also a problem on IE 11

[deakster]

Did a quick run of the docs on my local checkout, and while it does also leak, the Document Count stays the same throughout, unlike it does on the live site.

The difference between my local docs and the live ones is Disqus. There appears to be 3 Disqus related iframes included on each doc page switch, and the Document Count seems to go up by about 3 per document page change (even with GC), so I think it's fair to say that at the very least they are leaking.

But as I said, it is definitely not just disqus alone, even without it there are other DOM node and event listener leaks.

[chylvina]

1. the 'AngularJS Batarang' chrome extensions will inject js file into the webpage and hold the reference of angular's object such as scope, which will never be collected as garbage!
2. Use jQuery will cause memory leak. My version is 1.7.2.

[petebacondarwin]

We are going to drop Discus as it is not working as a way to request and
provide feedback on the documentation. Once this is gone, let's
investigate this further.

On 12 November 2013 10:00, chylvina notifications@github.com wrote:

@caitp https://github.com/caitp You are right, I clear everything in
$scope.$destroy
$scope.$on('$destroy', function() {
delete $scope.someFunction;
delete $scope.someObj;
})
And the memory leak drops. Thanks.
2.

What's more, the 'AngularJS Batarang' chrome extensions will inject js
file into the webpage and hold the reference of angular's object such as
scope, which will never be collected as garbage!
3.

Use jQuery will cause memory leak. My version is 1.7.2.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4864#issuecomment-28281051
.

[jbdeboer]

I reproduced this on my local, dev version which does not include disqus. I loaded the docs app and clicked on the first 10 pages in the left-hand panel

At HEAD (1.2.1), I saw 19686 DOM nodes

1.1.5: 18998 nodes
1.0.8: 18995 nodes

AFAICT, this is not a regression in 1.2.0. I've moved it out of 1.2.1 and into 1.2.x.

It is super important though. Once we've pushed 1.2.1, we should re-visit this issue.

[deakster]

I decided to look into this a bit more, after realising that some of my Angular apps were leaking too. The bad news is that there appears to be a number of entirely separate, unrelated sources of leaks. So ignoring Discus, which I already mentioned above, I found these:

1. Root scope of inline examples never gets destroyed correctly.

This line embedRootScope.$destroy(); at
https://github.com/angular/angular.js/blob/master/docs/components/angular-bootstrap/bootstrap-prettify.js#L253
doesn't do anything, since embedRootScope considers itself it's own root scope, so it will return immediately. This prevents any kind of scope cleanup operations from running in any of the documentation examples. This one is an easy fix: embedRootScope.$broadcast('$destroy');

2. ngAnimate leaks.

For the simple test case of switching back and forth between the input and form directive pages 10 times followed by a GC (and doing those steps over and over), it is actually possible to get rid of leaking entirely by removing ngAnimate. I went from this:

to this

just by removing ngAnimate. As you can see there are no leaks in the second screenshot (after a GC, all counts return to the same point).

I'm going to be looking at another ngAnimate issue which may very well tie in with this, so I will see if I can get to the bottom of it.

3. Detached elements, etc.

So this leaves the remaining leaks, which occur when switching to a different document page every time, for example going through the first 30 links down the left hand side. I did a comparison between two profiler snapshots, the first one taken just after loading the docs site, and the second one taken after visiting 30 document page links.

There's a bunch of detached DOM nodes, that are still being referenced somewhere, when they shouldn't be. For example, the divs of all previous examples are there, divs for tabs (presumably the ones on the example pages) and such. I know angular does maintain a bunch of detached nodes even under normal circumstances, but in the case of the docs, it really shouldn't be holding onto DOM from past pages.

The good news is that at this point (after removing ngAnimate) the leaking won't go up indefinitely, it will just go up for every new document page that you visit. So if you visit 10 different document pages, and you revisit all of those same pages another 20 times, there will be no extra leaking during the revisits.

[IgorMinar]

@deakster excellent work. I'm bumping this back to 1.2.1 since some of the issues can be fixed quickly.

[tbosch]

Looking into this...

[tbosch]

@matsko is looking into the ngAnimate problem