Fixed Memory leak. Clearing memory when deleting an DOM element.

[021]

Affected version

2.1.8 Patch 2

.when initializing a handler for xf-init, a handler is added to the elements array (xf/core.js line 7549-7570). But when you delete the DOM element to which it is attached, this handler is not deleted. Thus creating a memory leak.

The same thing happens due to the tooltip trigger cache xf/core/tooltip.js line 581.

When deleting elements from the DOM, such things should be cleared, because there is no point in them.

 

[Lukas W.]

For the average page visit it's probably still vastly more performant than a mutation observer instance. It still gets cleared on page navigation and for the average XF page, there's only so many things you can actually do before you'll need to load a new page anyway.

 

[021]

For the average page visit it's probably still vastly more performant than a mutation observer instance. It still gets cleared on page navigation and for the average XF page, there's only so many things you can actually do before you'll need to load a new page anyway.

.if you have automatically updated content on the page, then you do not have to wait long for the memory to clog. This is a memory leak and this is not normal anyway)

 

[Lukas W.]

I'd say if you're ajax updating the content in your add-on it would probably be your responsibility to garbage collect any remains for your specific case. XF itself rarely deletes any content that has listeners attached to it.

 

[021]

I'd say if you're ajax updating the content in your add-on it would probably be your responsibility to garbage collect any remains for your specific case.

.garbage creates a XF script, not mine. It must clean it. Even if I wanted to, I can’t do it

XF itself rarely deletes any content that has listeners attached to it.

This does not negate that a memory leak exists

 

[Kruzya]

It must clean it.

No, XF can't. JS API don't have any event about removing element from DOM tree.
I see only one solution. XF developers can define additional method in XF.Element like destroyElement($el) what should be called by third-party developers when they remove element from DOM tree.

 

[021]

No, XF can't. JS API don't have any event about removing element from DOM tree.
I see only one solution. XF developers can define additional method in XF.Element like destroyElement($el) what should be called by third-party developers when they remove element from DOM tree.

.DOMNodeRemoved
It can be fixed anyway and developers can do it.

 

[Kruzya]

DOMNodeRemoved

Deprecated more than seven years ago. Currently all browsers supports only MutationObserver, but on mobile devices have problems with him.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.0 Beta 3).

Change log:

Remove elements cache as in some circumstances it can cause a memory leak. Opt for using a specific cache for the place we used it.

There may be a delay before changes are rolled out to the XenForo Community.

 

[Kruzya]

Looks like this is fixed partially, because on Firefox i can receive memory leak on closures and arrays (sometimes - objects) if my tab is just idle right here, on "Forums" page.
For example, two shots from "Memory" tab in FF with capture time difference "8 minutes":


On this screenshots, we can see increased "closures" (also called "functions" by Firefox DevTools) and arrays count with decreased objects. Also DOM elements count decreased on 9.
Also i created additional snapshot when i wrote this post. All this time i leave "experimental" tab in "open" state.
If we compare region "objects" with another snapshots, XF continue "lose memory". Also region "strings" increases the existing objects too.


I'll try reproduce this problem on Chrome and edit this post.
On Chrome i can't reproduce this issue. Arrays and closures don't increases. Firefox issue?