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

Memory Leak in IE11 even after refreshing the whole page #541

Closed
ankurp opened this Issue May 31, 2016 · 39 comments

Comments

Projects
None yet
@ankurp

ankurp commented May 31, 2016

I have created a repo to demonstrate this issue. Just refreshing the page with a basic component keeps increasing memory in IE 11 and it never gets released
https://github.com/ankurp/polymer-webcomponent-IE-memory-leak

@robbecker-wf

This comment has been minimized.

robbecker-wf commented May 31, 2016

I verified this. Seems like to release the memory you need to close all of the IE windows.
EDIT: @ankurp can you try taking out the window.location reload every second and manually refresh? Or set the reload to longer, like 4 seconds?

I tried refreshing manually and the memory leak either isn't there, or doesn't seem as severe. The GC kicks in and handles things.

@ankurp

This comment has been minimized.

ankurp commented May 31, 2016

@robbecker-wf I tried manual refresh and even reduced the frequency of refreshes and memory usage still increases over time. I have seen the garbage collector not kick in after a lot of refreshes.

@ebidel

This comment has been minimized.

Member

ebidel commented Jun 1, 2016

Can you verify/isolate even more for us? Is it the inclusion of the polyfill alone? Is it adding the Polymer import. Is it creating a DOM module (full or empty)? There's a few things on the page that you can probably get rid of to better reduce the test case.

@robbecker-wf

This comment has been minimized.

robbecker-wf commented Jun 1, 2016

@ebidel It did not seem to be a problem with JUST the webcomponents polyfill. It needed both to happen. Is that your experience too @ankurp ?

@ankurp

This comment has been minimized.

ankurp commented Jun 1, 2016

Both are needed as you cannot just use webcomponent with either polymer or webcomponent polyfill in IE. Also this is the simplest example I created. It has nothing but a dom-module https://github.com/ankurp/polymer-webcomponent-IE-memory-leak/blob/master/index.html#L27 and nothing else on the page that can account for 2-3MB increases on every page refresh.

@ankurp

This comment has been minimized.

ankurp commented Jun 1, 2016

@ebidel I removed everything from the page except for a <h1> tag and including both polymer and webcomponents polyfill script and refreshing causes a memory leak of 2MB https://github.com/ankurp/polymer-webcomponent-IE-memory-leak/blob/master/index.html

@ankurp

This comment has been minimized.

ankurp commented Jun 1, 2016

@ebidel Also one thing to note is that memory leaks when both scripts are present. If you only include polymer.html or webcomponents polyfill then there is no memory leak but including both will cause a memory leak.

@dombre

This comment has been minimized.

dombre commented Jun 8, 2016

Any update on this?

I have the same memory leak as @ankurp.

The most minimal example I'm using is this:

<!DOCTYPE html>
<html>
  <head>

    <script src="https://polygit.org/polymer+:master/components/webcomponentsjs/webcomponents-lite.js"></script>
    <link href="https://polygit.org/polymer+:master/components/polymer/polymer-micro.html" rel="import">

  </head>

  <body>
  </body>
</html>

My conclusions are so far:

  • It needs both: Webcomponents and Polymer (Micro)
  • The refresh rate doesn't matter
  • You see the GC working but it will not free everything. Eventually IE will crash.
@ankurp

This comment has been minimized.

ankurp commented Jun 8, 2016

@dombre I agree and noticed the same thing. Just including polymer link and webcomponent-lite both together in an empty HTML page causes 2-3MB of memory leak that does not get cleaned up even after several refreshes. Memory is only released when browser or tab is closed.

@dombre

This comment has been minimized.

dombre commented Jun 8, 2016

In real world applications this gets worse. Of course, it doesn't matter for SPAs but for elements you include in a 'normal' Website this is bad. Here are some examples:

Example 1: https://www.polymer-project.org/1.0/ will loose ~40 MB every refresh:

polymer-projet-org

Example 2: https://shop.polymer-project.org will loose ~12 MB every refresh:

polymer-shop

My Test environments are:

  1. Windows 8.1, IE Version 11.0.9600.18321 (Update Version: 11.0.31)
  2. Windows 10, IE Version 11.306.10586.0 (Update Version: 11.0.31)

For reference, this is the memory consumption of the minimal example #541 (comment) with a 5 secondes refresh rate

1min-with-5s-rate
10min-with-5s-rate

@ankurp

This comment has been minimized.

ankurp commented Jun 10, 2016

Any update on this?

@ebidel

This comment has been minimized.

Member

ebidel commented Jun 14, 2016

@justinfagnani @azakus mentioned they had looked at memory leaks in IE at one point.

@justinfagnani

This comment has been minimized.

Contributor

justinfagnani commented Jun 24, 2016

Update: @garlicnation is taking a look at this

@joao-arvins

This comment has been minimized.

joao-arvins commented Jul 11, 2016

Any updates on this issue?

Also is there any quick patch we can use in the mean time as a temporary fix?
I've tried to use older versions of the library but the problem is still there.

@garlicnation

This comment has been minimized.

Contributor

garlicnation commented Jul 11, 2016

After extensive experimentation, I've determined that this is definitely an IE issue, not a webcomponents issue. It's possible to get IE11 and Edge to leak memory by creating a variety of different platform-provided objects.

Reported issue: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8020622/
The reproduction and bug report in IE Edge as well as 11, so there's a good chance they'll fix it.

I've experimented with a couple of mitigation strategies that show some promise in reducing, if not fixing, this issue. My next step introduce the mitigations into the polymer-element-catalog and determine the effect they have in a real-world application. If one of the patches I come up with has a significant effect, I'll update this bug with it and/or consider patching it into the polyfill until the underlying IE issue is resolved.

@kstenson

This comment has been minimized.

kstenson commented Jul 12, 2016

@garlicnation can you give more detail of your approach? We have an application using this via x-tags and even refreshing the page is not releasing memory.

I would be happy to test out any patches you have in our app for testing a real life app.

@jbotelho2-bb

This comment has been minimized.

jbotelho2-bb commented Jul 27, 2016

@garlicnation any chance you could share what platform-provided objects cause the memory leaks?

We are currently seeing a similar leak on our site, and are in contact with a support engineer at Microsoft. We're having a hard time clarifying that the issue is a bug in IE though, as opposed to an issue in our code or the webcomponents.js code.

@felvhage

This comment has been minimized.

felvhage commented Aug 4, 2016

Would also be interested in details about mitigating this problem now and any updates on a polyfill solution.

@chiefcll

This comment has been minimized.

chiefcll commented Aug 13, 2016

@garlicnation - Can you provide an update on this issue and if you we're able to come up with any work arounds?

@jbotelho2-bb

This comment has been minimized.

jbotelho2-bb commented Aug 13, 2016

For anyone investigating this, it seems to be related to circular references of some sort, but I'm waiting for more info from Microsoft about this. @garlicnation, I think that we will need a workaround/mitigation available, since even if Microsoft comes up with a patch, it won't get pushed out and applied to end-users very quickly.

I also put a workaround in Polymer/polymer#3430 for cases involving a framework like Polymer, where you don't explicitly need HTML imports.

@kstenson

This comment has been minimized.

kstenson commented Sep 13, 2016

Any update on this issue, we're having real issues with our call centre applications where a new call triggers a new session using a browser reload with querystring params.

Like I said in a previous comment to @garlicnation even a quick post to give use a pointer to where you see this issue arising would be a big help.

@ergo

This comment has been minimized.

ergo commented Sep 15, 2016

Any news on this?

@bbsteventill

This comment has been minimized.

Contributor

bbsteventill commented Oct 26, 2016

I have a fix for this; has to do with the document.implementation. From what I found if you have any non-standard attributes/properties that you are putting on a document, IE will leak. I also have submitted a PR for memory leak fixes with in Polymer (Polymer/polymer#3964).

Other things of note, some polymer elements such as paper-dialog will use elements like
iron-overlay-manager; in that code if you look at

Polymer.Gestures.add(document, 'tap', this._onCaptureClick.bind(this));
document.addEventListener('focus', this._onCaptureFocus.bind(this), true);
document.addEventListener('keydown', this._onCaptureKeyDown.bind(this), true);

this may cause a memory leak as well, so you may want to add an event wrapper on document AND window that will remove the events on page unload (the problem is that when you bind, it creates a new fn reference that IE doesnt know how to clean up - I have attached a very aggressive unload script to this issue(Polymer/polymer#3430) )

Anyway like I said I have a PR ready to go that will fix the memory leak with the imports.

I am just waiting for approval to submit a PR. Should be submitted by the end of the week

@ergo

This comment has been minimized.

ergo commented Dec 13, 2016

Should this get closed? It seems that #644 fixes this - can we have a confirmation?

@kstenson

This comment has been minimized.

kstenson commented Dec 13, 2016

@ergo I did a quick check with the latest build from master and was still seeing a memory leak issue. My project doesn't use html imports so i'm not sure the changes in #644 are relevant.

@garlicnation in your initial comments you mentioned a couple of mitigation strategies, do you mind sharing more information?

@bbsteventill

This comment has been minimized.

Contributor

bbsteventill commented Dec 13, 2016

@kstenson you may want to look at this issue: Polymer/polymer#3430
I added this script; it is not perfect but it works for me.
https://github.com/Polymer/polymer/files/480498/polymer_memleak_cleanup.js.txt

Things to be aware of, I had to manually clear out the CustomElements.registry on page unload; also it looks like IE has a memory leak issues with root shadow dom nodes. (for example adding properties directly or putting observers on the root nodes)

@kstenson

This comment has been minimized.

kstenson commented Dec 14, 2016

@bbsteventill thanks for the link, we aren't using polymer with this lib so we don't have access to CustomElements.registry

@bbsteventill

This comment has been minimized.

Contributor

bbsteventill commented Dec 14, 2016

@kstenson CustomElements is the polyfill in webcomponentsjs that adds support for CustomElements; hense why I suspected/hoped that script or parts of it could help you out.

https://github.com/webcomponents/webcomponentsjs/blob/master/src/CustomElements/register.js

@kstenson

This comment has been minimized.

kstenson commented Dec 15, 2016

@bbsteventill ah I thought this was a polymer object built on top, thanks for the pointer I will check it out.

@notwaldorf notwaldorf added the v0 label Jan 23, 2017

@kevinpschaaf

This comment has been minimized.

Contributor

kevinpschaaf commented Jan 26, 2017

Fix in #644 was reverted in #665 due to a problem with the implementation leading to custom elements in shadow roots being missed by the custom elements polyfill observers. This will need an alternate fix.

@liraniom

This comment has been minimized.

liraniom commented Mar 14, 2017

Hello, Any update on this?

@alvarezguille alvarezguille referenced this issue Apr 7, 2017

Open

Polymer 2 Memory Leak in IE11 #4511

1 of 6 tasks complete
@jdulude

This comment has been minimized.

jdulude commented May 3, 2017

+1 for an update on this...

@Jeff17Robbins

This comment has been minimized.

Jeff17Robbins commented May 8, 2017

+1 for an update, please...

1 similar comment
@xingchch

This comment has been minimized.

xingchch commented Jun 29, 2017

+1 for an update, please...

@jbotelho2-bb

This comment has been minimized.

jbotelho2-bb commented Jun 29, 2017

We've been using a fork of webcomponentsjs that includes #664 to solve the memory leaks we've been seeing when using Polymer. Since we don't use shadow DOM, this has been fine for us.

Also, at this point it's probably not worth patching version 0.7, since 1.0 is out and will be what most of the webcomponentsjs and Polymer devs will be focusing on. I would hope the webcomponentjs devs would look into this on 1.0 (if it's still an issue), since the world is stuck with IE11 as a supported browser until 2020.

Of course if anyone has their own patch they'd like to submit, by all means open a PR.

@jhuesos

This comment has been minimized.

jhuesos commented Oct 30, 2017

Is this issue solved in WebComponentsJS v1.x?

@ttcremers

This comment has been minimized.

ttcremers commented Oct 31, 2017

Is this issue solved in WebComponentsJS v1.x?

@jhuesos I tested this yesterday and the issue is still there. I was able te reproduce by creating a html document which script includes webcomponentsjs, on every reload it leaks even with an empty body. I tested with webcomponentsjs 1.0.17.

@jbotelho2-bb

This comment has been minimized.

jbotelho2-bb commented Oct 31, 2017

May also want to track Polymer/polymer#4511

@TimvdLippe

This comment has been minimized.

Contributor

TimvdLippe commented Sep 17, 2018

Thanks for the issue. It has been a great while since this issue was opened. Sadly, this issue misses a live reproduction with the most recent version of the webcomponents polyfill for us to be able to debug and potentially fix. Versions 1 of the polyfills fix a large amount of issues, probably including this one as well.

Please see the CONTRIBUTING.md for guidelines on filing issues. You can start from this jsBin template as a starting point and link it in the issue template under "Live Demo".

Feel free to file a new issue following these instructions if you can still reproduce this issue with versions 1 of the polyfills. Thank you!

@TimvdLippe TimvdLippe closed this Sep 17, 2018

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