New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Polymer will lead to memory leaks in Internet Explorer 11. #3430

lorrylockie opened this Issue Feb 17, 2016 · 22 comments


None yet

lorrylockie commented Feb 17, 2016

Polymer will lead to memory leaks in Internet Explorer 11.

  1. e.g "open site "" in Internet Explorer 11
  2. then refresh page some times , observe the system ram, would raise up constantly

This comment has been minimized.


ebidel commented Feb 17, 2016

The site is built on polymer 0.5. There's been a ton of perf work since then.

Can you check a 1.0 site?


This comment has been minimized.

lorrylockie commented Feb 18, 2016

OK , this is a smallest simple case



This comment has been minimized.


ebidel commented Feb 18, 2016

screen shot 2016-02-17 at 7 43 12 pm


This comment has been minimized.

lorrylockie commented Feb 18, 2016

@ebidel Sorry, I had updated link


This comment has been minimized.


mohanaravind commented Feb 20, 2016

We too are facing memory leak issue in our project when running in IE 11. Nevertheless we noticed an improved performance from 0.3 to 1.0 Polymer


This comment has been minimized.

ankurp commented May 27, 2016

@ebidel any update on this?


This comment has been minimized.

dombre commented May 30, 2016

Defining a polymer element seems to be enough to get a memory leak in IE11:

<dom-module id="bye-bye-memory"></dom-module>

In IE11 this will cause a 1 MByte memory leak every refresh/request. It will get worse if you define more elements. For example my application has ~110 elements and I will loose ~30 MByte every refresh. On my system IE will stop working at about 1.6 GB (looking at "WS private" in "Process Explorer" from sysinternals).

Here is a small example (it will automatically refresh the browser every second):

For future reference, here is the code of the example:

<!DOCTYPE html>

    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

    <base href="">
    <script src="webcomponentsjs/webcomponents-lite.js"></script>
    <link href="polymer/polymer.html" rel="import">


      // After every second, the memory will increase by ~3 MByte. GC is kicking in sometimes but it will not collect everything.
      setTimeout(function() {
      }, 1000);



  <body spellcheck="false">

    <!-- Define a custom element -->
    <dom-module id="simple-element">
        <div>Custom Element</div>

        Polymer({ is: 'simple-element' });

    <!-- An empty element will also leak! -->
    <dom-module id="even-simpler-element"></dom-module>



  • it doesn't matter if the element is defined inline or included by a HTML-Import. In both cases the memory leak will occur.
  • I have also tested this example with HTML Import and lazy registration enabled. Same result.
  • Firefox and Chrome doesn't leak

This comment has been minimized.

sadanand8005 commented Jun 2, 2016

Not just IE 11 memory leak happens on IE 10 as well. Any updates on this issue?


This comment has been minimized.

arichnad commented Jun 7, 2016

Any updates? I think IE11 is the most up-to-date version of IE on Windows. Sorry to pile-on, but we're pretty desperate for information.


This comment has been minimized.

felvhage commented Aug 4, 2016

This issue is probably related to (if not the same as) webcomponents/webcomponentsjs#541.


This comment has been minimized.

jbotelho2-bb commented Aug 13, 2016

We were able to git rid of the leak caused by the HTML imports polyfill (webcomponents/webcomponentsjs#541) with a workaround where we bypass HTML imports entirely for IE, and just dump our vulcanized Polymer bundle into the page. Its not a true fix, but if you're just using Polymer and not directly relying on the HTML import APIs, it works well:

window.loadHTMLImport = function(path) {
    var isIE = /Trident/.test(navigator.userAgent);
    // Workaround for IE
    if (isIE) {
        $.get(path, function (html) {
            var $container = $('<div></div>').hide();
    // Fall back to regular imports for other browsers
    } else {
        $('head').append($('<link rel="import" />').attr('href', path));
// ...

This is almost equivalent to embedding the elements in the page, like in the example @dombre gave, except we are also dropping Polymer straight in the page instead of importing it.

If you try this workaround, keep in mind that other elements and libraries may still cause a leak (we noticed neon-animations and certain analytics libraries re-introduce some leaking).


This comment has been minimized.

glitchbreaks commented Aug 23, 2016

Hey @jbotelho2-bb where do you put this fix? And then what does the last line replace: loadHTMLImport('/assets/my-polymer-bundle.html');


This comment has been minimized.

petelee-gh commented Aug 24, 2016

Hi @jbotelho2-bb, I tried your workaround by vulcanizing one of our custom elements, but I still see no difference in memory utilization. I still have to include the webcomponents[-lite].js in order for the custom element to work properly, and every refresh of the page still has about the same 6-7 MB increase in memory as the non-vulcanized version. Anyone else have any luck trying this with a custom element?


This comment has been minimized.

eugef commented Aug 25, 2016

I've inlined the vulcanized element on the page (so I am not using HTMLImport at all) but I can still see increase of memory consumption in IE after each page refresh.


This comment has been minimized.

jbotelho2-bb commented Aug 25, 2016

Sorry that didn't work for you guys; it looks like that fix helps on our site, but not on a minimal test page. So I put together a test page with nothing on it but webcomponents.js, Polymer, and paper-button, to test some other fixes we've been trying. Here is another workaround that seems more promising:

This basically clears out references to custom elements in the CustomElements.registry, which seem to interfere with IE's garbage collection.

If you click the little blue button on that plnkr link to launch it into a separate window, you can keep refreshing to test the memory leak in IE (it doesn't work properly in Plunker's edit/preview mode). Keep in mind that you need to check memory consumption with Task Manager or perfmon (looking at Working Set Memory), as the dev tools in IE have their own memory leaks.


This comment has been minimized.

jdmedina commented Aug 25, 2016

@jbotelho2-bb Interesting idea. I tested your sandbox but I do see and increment in memory usage over the refreshes... In my testing I saw about ~80Mb in memory that doesn't get freed after 20 refreshes.

I also tested the fix in our app and the memory was still not freed. It's worse in our case due to the number of Polymer components used.

Side note: stumbled upon this:

Interesting read about the cause of IE memory leaks and Microsoft's attemps to fix them but... no dice

@tjsavage tjsavage added the 1.x label Sep 8, 2016


This comment has been minimized.

ergo commented Sep 15, 2016

Any news on this? I did try latest IE and EDGE - i did some refreshes on the shop demo page and ended up with over 300mb of ram that was not getting reclaimed easly so there seems to be a problem of some kind.


This comment has been minimized.

steventill commented Sep 19, 2016

So I have a bunch of fixes and it is no longer leaking on my system; I am currently working on making a pr.

In addition, because it is IE, there are some elements that have event handlers that cause memory leaks, and you may have added some in your code, for example (iron-overlay-behavior):

document.addEventListener('tap', this._onCaptureClick.bind(this), true);

(the issue with the above example is the .bind(this) - if you remove it IE knows how to clean that up)
Just to be safe I would add a wrapper to remove all events added to document and window

I have attached my cleanup code (keep in mind I am very aggressive in trying to clean things up); and I should have a PR ready here today or tomorrow. I just need to make things cleaner first



This comment has been minimized.

mwcz commented Sep 20, 2016

Does anyone have a sense of how the memory leak is happening? It seems to me that every reference in the JS heap, or DOM, or global space, should be completely cleared on refresh. It smells like there could be an IE vuln here.


This comment has been minimized.

jbotelho2-bb commented Sep 20, 2016

@mwcz basically IE and Edge have several cases where having a circular reference between DOM elements and JavaScript objects causes leaks across pages and refreshes. This is definitely a bug in IE, but its been hard to get Microsoft to do much about it without having a minimal test case that reproduces of the issue (ie. without importing all of Polymer and webcomponents.js).


This comment has been minimized.

glitchbreaks commented Sep 21, 2016

Excuse my naivete but where are you putting your polymer_memleak_cleanup.js code @steventill? Is this in the polymer.html? Every element with .bind(this) circular reference? The app.js or it's on script file? I already modified my copy of the polymer.html with your pending changes the useCache mod.


This comment has been minimized.


bbsteventill commented Sep 21, 2016

I put it in a script tag in the main doc, as long as you put it before you import your html files you will be fine. For example:

<script src="/web_components.js"></script>
<script src="/polymer_memleak_cleanup.js"></script>
<link rel="import" href="/polymer.html" />
<link rel="import" href="/your-element.html" />

there are still mem leaks, for example for some of my elements I had to dynamically load my .html using ajax and disable the eventDataCache, a small fix with the URLResolver and there is a problem with the weak map with the _recordEventHandler in the events.html (that is a preview of all of the changes that I have for my pr, I just need to get permission for the cla)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment