Closed distributedlock closed 9 years ago
Thanks for pointing that out!
Interesting that the other GCs will clean this up - looking at it, that is a nasty little bug that I'm somewhat surprised the other GCs do pick up!
It is worth noting that TableTools is shortly to be replaced by two new extensions - Buttons and Select. So it might be a while before this bug is in a released version of TableTools. I'll likely wait a month or two after the new plugins are released (this method) and the issue a final bug fix release of TableTools.
No problem.
Yeah, it was a little odd how the new GCs (Firefox, Chrome) are cleaning it up properly and IE wasn't.
Thank You for your commit, I can confirm the memory leak no longer exists with the version based on your commit in the IE suite.
Hi,
There is a memory leak that occurs in IE 9 (possibly IE9 and below), I have not tested this with IE9+. The leak only occurs in the IE suite. I have tested this in Chrome and Chrome's garbage collector handles it properly.
This issue occurs when you destroy a
DataTable
-ized andTableTools
-ized table usingtableName.destroy()
function and again redraw the table by initializingDataTable
again withTableTools
buttons. We are reinitializing a table multiple times in a single page and every time a DT TableTools init occurs, the whole table info including DOM tree is stored inZeroClipboard_TableTools.clients
object. Now, when an old table is deleted, Chrome'sgc
will know that the deleted clients inZeroClipboard_TableTools.clients
are no longer being used and purge from memory. IE doesn't know that (because it'sgc
is terrible) so, the memory usage gradually keeps rising.Fix for this issue:
ZeroClipboard_TableTools.clients = {};
by forcefully emptying clients that are no longer present in the DOM which will trigger IE'sgc
to purge from memory.Maybe
table.destroy()
function can remove dead clients in ZeroClipboard when DataTables and TableTools are integrated? This might be a better fix than the way I am doing it.