I'm submitting a ... (check one with "x")

[X] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When triggering ComponentRef.destroy(), no browser memory is ever released. Any injected dependencies are all still there and running, even though the component is gone.

Also:
When bootstrapping an app within an iframe, destroying that app and removing the iframe from the DOM does not release browser memory.

In both of these scenarios, browser memory builds up over time and the browser tab and angular app lock up or crash. Injected dependencies are created, but never removed.

Expected behavior

Browser memory should be released as apps and components are destroyed.

Minimal reproduction of the problem with instructions

STEPS TO REPRODUCE

REPRODUCING DEPENDENCY LEAK

1. Run the Tour of Heroes plnkr in Chrome or IE
   https://plnkr.co/edit/R9axXVtjep5VO8hWygpA?p=preview

2. Open the js console and watch the logging in the hero service, which does not stop after destroying the app.

• Note, this is the Tour of Heroes example, except that after the app is bootstrapped in main.ts, I've added a 15sec timer that runs ref.destroy(). Additionally, in the hero.service.ts file, I added a console log in the constructor that prints every second. You can see that the service continues to run even after triggering .destroy() on the component ref.

REPRODUCING IFRAME LEAK

1. Run the Tour of Heroes live example in IE 11
   https://angular.io/resources/live-examples/toh-6/ts/eplnkr.html

2. Open F12 dev tools, click on Memory and click "Start profiling to begin a performance session"

3. Make changes to the files by adding line breaks. Every time the app reloads in the iframe the memory will grow. After about 15 minutes of this the app will lock up due to the IE tab hitting the 1.5Gb memory limit. If you test with app that has more dependencies, it will lock up much faster.

This can be reproduced in Chrome too, it just takes longer for the memory leak to build up that much.

What is the motivation / use case for changing the behavior?

Large-scale angular apps that use iframes or rely on destroying components will leak memory over time and eventually crash or lock up.

Please tell us about your environment:

Mac OS 10.11.6

• Angular version: 2.0.X

Angular v2.4.1

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

all

• Language: [all | TypeScript X.X | ES6/7 | ES5]
  all
• Node (for AoT issues): node --version =