Unit tests in IE11 get progressively slower with angular-bootstrap >=1.1.0

[mikedaly]

We have a fairly large angular app that utilizes ui-bootstrap. We also have a fairly extensive set of unit tests (~1900) that exercise as much of the system as we can in isolation. We run our unit tests using karma and jasmine against the latest version of Chrome and IE11.

During a recent upgrade from ui-bootstrap 0.14.3 to 1.2.0, I discovered that in IE11 each test in a run gets subsequently slower. Eventually, the tests slow down to the point that IE11 stops responding, and the test run fails. There's no one test that starts the sequence; each one just takes a little longer. At about 800ms for a single test, the run fails. Unit tests in Chrome behave the same through all versions.

I walked backwards through ui-bootstrap versions and discovered that the behavior was introduced in 1.1.0; 1.0.3 and all previous versions do not have this problem, and all subsequent versions do, including the latest (1.2.0).

I'll see if I can put together a set of simple unit tests that show the problem. It has to be a series of tests, though; running a single test works fine, and even running a small number of tests you might not notice the change.

Angular: 1.5.0
UIBS: >=1.1.0
Bootstrap: 3.3.6 (via bootstrap-sass)

[icfantv]

Closing as duplicate of #5496.

Please extend us the courtesy of reading our project documentation and searching existing issues filed (both open and closed) before opening a new issue.

[mikedaly]

I do not believe that this is a duplicate of the linked issue (which I did find before posting). As evidence I present the following:

• The bug I reported occurs in versions 1.1.0 and greater. It does NOT occur in 1.0.3 or earlier. (The linked bug was identified as being introduced in 1.0.2)
• The bug I reported only occurs in IE. It does not affect Chrome. (I have not yet tested other browsers.)
• The bug I reported isn't just a small performance issue that adds 1-2 seconds. Each spec in our suite takes longer than the previous spec, so eventually each spec is taking 800ms+ and the karma timeout kills the whole run. The entire test suite run takes 45 seconds in Chrome and 9 minutes in IE before it fails. Using v1.0.3 it takes about the same amount of time in both browsers.

This bug prevents us from running our test suite in IE at all.

I have not looked at the commits between those two versions (1.0.3 and 1.1.0) when the bug was introduced. But I suspect that there is something added to the DOM that isn't being removed, thus accumulating over long test runs since the DOM is not recreated between each spec. I surmise that whatever is affecting our tests would also (over time) affect a production system.

[wesleycho]

Sounds like a potential memory leak - what components are you using?

[icfantv]

@mikedaly, thanks for the additional details.

[mikedaly]

We are using the following components:

• Buttons
• Collapse
• Dropdown
• Modal
• Progressbar
• Tabs
• Tooltip

I'll see if I can reproduce the slowdown with an isolated set of tests.

[cwilsn]

I am having the same problem and for me the problem presents itself in when running Phantom JS as well.

I have about 375 tests and they typically ran between 15-16 seconds. When upgrading to >=1.1.0 I started seeing the test times increase by about 2x and then after the 2.0.0 release they time went up by about 3.5x.

After a bit of debugging today it seems as it all stems from the run block the injects the CSS in to the head. So the leak is present only when you include the ui.bootstrap module (does not require you loading any directive or service).

When the run blocks created here are omitted the run times drop back down to normal.

[wesleycho]

Hm, that would make sense - I think we can optimize around here by creating a flag like angular.$$bootstrapCss and toggle that true inside that block & not execute the block if it is true.

PRs welcome

[cwilsn]

@wesleycho I may have time to work on a PR this evening but just so I understand, when would it need to be true and when would the flag need to be false?