Issue: Table size is being doubled by STS.
Possible Cause: Memory leak during a dynamic table rebuil
Symptoms: The variable newRows is not being reset when the table is
rebuilt and and the init is called a second time AND the user clicks on
the column that was sorted the last time before the table was rebuilt.
Hence newRows contains references to rows that do not exist any more
in the table, and as such those rows are ADDED to the table instead of
being moved. The net result is the table size is doubled with old junk
data.
Solution:
1) Add the following line to the init function before this.run();:
this.newRows = new Array();
2) Add "&& that.newRows.length > 0" to the headingClicked function
so that you have the following:
if (table.id == that.lastSortedTable && column ==
that.sortColumnIndex && that.newRows.length > 0 ) {
newRows = that.newRows;
newRows.reverse();
// otherwise, we have to do the full sort
} else {
I have made the changes locally and have tested it and it is working
fine.
You may be asking why would I ever need to call init more than once?
Because the table I am using is dynamically regenerated when ever the
user wants and is able to change the number of rows and columns.
Hence it init is not called each time the table is regenerated, then if
they increase the number of columns, those columns will not be
sortable. Besides since STS is setting the attribute
standardistaTableSortingInnerText the sorting of the new table with
new data may not be as expected!
Copy of the source of the code that is dynamically generating these
tables can be found at:
http://scott-tabar-safari.blogspot.com/2006/07/safari-table-sorting-
performance-issue.html
Also a copy of the HTML that has the fixes applied and the dynamic
table generation is attached so you can better see where the fixes were
applied. Replace the copy of standardista-table-sorting.js with the
most recent version to see the failures.
Example with Solution Applied to STS