ngSanitize 1.5.0 triggers Internet Explorer memory leak

[PhilipWallin]

The changes from v1.4.8 to v1.5.0 of angular-sanitize triggers a memory leak in our project. When using Internet Explorer 11 with other javascript libraries each pageload will increase the memory usage, until the browser stop working. I've put together an example project which just have the minimum amounts of script tags in the header to reproduce the problem. Every time I refresh the page Internet Explorer 11 will leak memory, and will eventually (at around 1.2GB memory usage for me) get random renderer and javascript errors. If I remove either of "es6-shim.js", "kendo.all.min.js", or "angular-sanitize.js" the memory leak wont happen. In the example project I have simplified the angular-sanitize code as much as I could to show what functionality is triggering the memory leak for me.

(As the file attachment seems to be broken, here is a link to the example project: https://dl.dropboxusercontent.com/u/775659/Leaker.zip)

Notes:

• If the IIFE in my simplified script is removed the memory leak wont happen.
• If "createHTMLDocument" isn't called in an inner function the leak wont happen.
• If "documentElement" isn't accessed on the newly created HTML document the leak wont happen.
• If an angular module isn't registred the leak wont happen.
• When changing any of the conditions, for example using angular-sanitize v1.4.8, memory usage could of course still increase. The difference being that the memory is temporary, will be capped, and will clear if you go to another page. In my example project the leak wont cap, and will remain even if you leave the page.

[Narretz]

Thank for the detailed write-up. I can confirm that there's a memory leak, and that the steps to prevent it work. I find removing the IIFE especially interesting. I've also experienced that the leak isn't as bad if you simply remove the createThingy function and create the doc straight like this var thingy = window.document.implementation.createHTMLDocument("doccy")
So it looks like IE11 doesn't like it when this is inside a function.
I wonder, how big of an increase do you see per page load? For me it was around 20MB in your initial example, and with the fn removed around 10MB.
Maybe we can remove the IIFE in the sanitize code, too. However, I think there's always one outer IIFE around the whole sanitize module, so we might not get it that way.

You should definitely open a bug report about this at MSDN Connect. They don't have a great track record with responses, but it's better than nothing.

[Narretz]

The only reliable solution I've found is indeed to remove all IIFE from the angular sanitize code (there are 2). But we can't remove the outer one, because the keeps all our stuff private.

[Narretz]

Another thing, are you using Kendo Professional or Open Source Edition?

[PhilipWallin]

In my tests the memory growth is around 25-30 MB each refresh. I'm using Kendo Professional in the project.

In my simplified script example I can add the whole inner IIFE to trigger the leak, and add just the code of the inner IIFE to avoid the leak. This, however, does not seem to work as easily on the full angular-sanitize.

I will report this to Microsoft too, but I figured that was... more of a long term solution :)

[Narretz]

The thing is that the trigger isn't that common (since you need both kendo ui and ES6 Shim), so I'd like to refrain from trying some brute force approach in ngSanitize. It would be interesting to find out what exactly triggers it in ES6 Shim / Kendo. Problem is that they their distributables are huge.

[PhilipWallin]

I figured as much, which is why it's really annoying finding a bug which is triggered by three different libraries. I considered binary searching for triggers in the other projects too, but deemed it to not be worth the time, as even if I found that X + Y + Z triggers a problem it would in the end still be an IE bug. In best case I could prove it's a common scenario, which would make at least one of the libraries want to avoid it.

[petebacondarwin]

I don't think that this issue should block release of 1.5.0 - I am moving it to the 1.5.x milestone.