JS event listeners are added and never removed

[jose-torres-marin]

Describe the bug
Looking at the performance monitor tab in dev tools, I see the event listeners count increases but never decreases. I would like to know if this might cause a memory issue as users keep browsing the app.

To Reproduce
Steps to reproduce the behavior:

1. Checkout, install, and run the demo website
2. Open performance monitor on Chrome dev tools
3. Use the up and down arrow keys repeatedly to switch focus between the first and second elements
4. See JS event listeners increasing and never decreasing

Expected behavior
JS event listeners to remain stable if no new elements are added to the DOM

Screenshots

Additional context
This is more a question than a bug. I'm not sure this is actually a problem since the JS heap doesn't seem to increase too much.

[predikament]

@jose-torres-marin: Hello! Thanks for reaching out.

This is likely a non-issue, as you said the heap size is not changing and if we actually had a memory leak here (of importance) we would be well aware, due to having been informed by multiple users of the library on several low-end devices (including ourselves) on a daily basis.

We will have a look however, just to check if there's anything worth cleaning up there based on your observations.

Thanks.

[spikything]

Interesting. The question is: Can JS event listeners KEEP increasing until it affects performance?

This may not have been noticed in the wild, since real world usage means components are unmounted as users/testers navigate to another part of their app.

Also, if you look closely at the graph, heap DOES actually stay above baseline - expected if images or new components were mounted. So this is worth testing for much longer than what looks like (from the graph) 15 seconds of interaction. The redundant listeners may be reclaimed above a certain limit; they may not.

This may also only be noticeable on devices that developers/testers no longer test on, but that users will still own, e.g. webOS 5, Tizen 5. But that doesn't mean it's not an issue. I have seen similar problems on older Freeview devices with 'react-lazy-load-image-component', whereby intersection observers are never cleaned up on their ancient browsers (usually equivalent to Chromium 68).

This may be worse on the older browsers that the oldest TVs out there employ. And it will likely become a performance issue before any memory leak is noticeable.

[predikament]

...
This may be worse on the older browsers that the oldest TVs out there employ. And it will likely become a performance issue before any memory leak is noticeable.

We've been developing, testing and running this library in production for nearly seven years across a wide range of devices, including older Samsung TVs (e.g. Orsay), set-top boxes, and WebOS versions (e.g. 3.x), as well as current devices and models. In that time, we haven't seen evidence of unbounded listener growth causing performance issues in practice.

That said, the observation is definitely reasonable, especially for long-running sessions or older browsers - So we will make a note to take a closer look, to ensure listeners are consistently cleaned up and confirm that nothing is lingering that could cause issues over time.

If you've observed a clear impact from this in your own projects, please feel free to open a PR or share any additional details, so we can investigate further.

Thanks for the feedback!