Memory leak in Karma+Jasmine tests and event listeners

[Eddman]

I'm using @angular/material2 and it creates an event listener in a service /core/style/focus-origin-monitor.ts. The listener is bound to window (some to document as well) and it is fine for my app as Angular uses a single instance of this service.

However once I try to run my Karma test suite it generates a huge leak and chrome crashes. The problem is that whenever I create a component out of a TestBed (each spec) the listener is created and registered. It holds references to the TestBed, component, view, test data, etc.

I always thought that Zones are isolated so once I finished a spec I would expect that such listener is removed. However I've found out that listeners are registered in ProxyZoneSpec and never removed. The zone is simply set to null.

Shouldn't it remove the listeners before we run next spec? Or is it more a bug of @angular/material2?

[JiaLiPassion]

@Eddman, I am not sure I understand your issue.
you mean that

1. angular/material2 create a event listener and bound to window
2. karma test create a component out of testbed and reference to all stuffs inside your test.
3. ProxyZoneSepc registered eventListener and not released??

[Eddman]

@JiaLiPassion:

1. Yes
2. The testing module below includes angular/material2 modules that provide FocusOriginMonitor service. Once I create a component using TestBed.createComponent Angular creates instances of all services/components needed and prepares a "test" view. At this point the listener is registered. (The process repeats for each spec)

beforeEach(() =>  {
    TestBed.configureTestingModule({
        includes: [SomeMdModule],
        declarations: [MyComponent]
    }).compileComponents();

    component = TestBed.createComponent(MyComponent); 
}

3. Current zone is ProxyZoneSepc so I assumed that it should release the listener...but I was obviously wrong 😄 as it does not...

I'm sure that it has to be categorized as a bug as it creates a massive mem-leak. And will create for any other library/app that registers window/document listeners.

But the question is: Is it ProxyZoneSepc in combination with Jasmine-patch who should remove it?

As there is no ngOnDestroy of services I assume there is no way for angular/material2 to know that the listener has to be removed/released.

[JiaLiPassion]

@Eddman , Thank you for the detail information, I am not familiar with angular/material2, but I think maybe who addEventListener should be responsible for releasing it, or maybe you can currently add some code in afterEach to manually remove the listener which added to window to just walk-around this issue.

[Eddman]

@JiaLiPassion: In general I agree.

What I do not understand: the zone where I call addEventListener persists until I call removeEventListener? And each event is executed in this zone? Even if my main execution in this zone already ended?

I see here a problem that libraries are designed to run once and test suites run in multiple contexts/specs. Would be nice if we can "finalize" the ProxyZoneSepc without manually calling removeEventListener...Will solve many nightmares 👍

Zone already overrides this methods so this may be a good point for enhancement.

[JiaLiPassion]

@Eddman .

What I do not understand: the zone where I call addEventListener persists until I call removeEventListener? And each event is executed in this zone? Even if my main execution in this zone already ended?

Yes, your understanding is correct. if you don't removeEventListener, the zone and listener will be kept in memory, but I believe it will be GC if zone, listener and eventTarget (such as button) are not used.

I see here a problem that libraries are designed to run once and test suites run in multiple contexts/specs. Would be nice if we can "finalize" the ProxyZoneSepc...Will solve many nightmares

do you mean auto clear the listener which created in the zoneSpec after a case is finished?
I think you can do that by add removeAllListeners() in afterEach() method.

[JiaLiPassion]

close for now for no further information.