Chrome: "Uncaught RangeError: Maximum call stack size exceeded"

[streetLAMP]

When using the tablesorter with the page sorter (and columns and zebra widgets), I've found that the Chrome browser chokes much, much sooner than FF or IE or Safari browsers. I'm testing a table with 460 rows and approximately 180 columns. FF/IE/Safari are all able to render this in your fork of tablesorter just fine (requires 8 seconds total load time); however Chrome throws the following error message: "Uncaught RangeError: Maximum call stack size exceeded". Maybe an issue of recursion with verifying that all column cells exist and have data? For what its worth, I have all TH cells using the specific parser information (ie class="sorter-digit"). Have you seen this before? Can you fix this issue? If you like, I can post an example on jsfiddle. Thanks, in advance, for your thoughts!

[Mottie]

I haven't run into this problem before, if you want, you can just email me the file (gmail account, user name wowmotty) or post a jsFiddle, but yes I'd like to see a demo of the issue. Thanks!

[Mottie]

I'm still not sure about this error, but I've updated the plugin to version 2.3.2 and I did notice that the zebra and columns widget were using an incorrect selector. Hopefully it is fixed now.

[Mottie]

Any word on if this latest fix still has this error?

[streetLAMP]

I tested today using your newest files and the recent fixes do not have any effect (positive or negative) on this issue. Just sent you an email with two demo files (one works, one does not) and the specific error message. Looking forward to your hearing what you think. Thanks!

[Mottie]

Ok I think I found the problem... it's the zebra and column widgets!

So for now, don't use the widgets and I'll try to optimize them, Maybe css selectors would be an even better idea.

Honestly, I think it's a bit overboard to have a table with 240 columns and 260+ rows...

[streetLAMP]

I'm super-happy you found the problem! I can omit the widgets, but would really love to be able to re-include them again soon, if you think a fix might be possible. CSS selectors might hold promise. Let me know if you want help testing or kicking ideas around.
(My clients have lots of data; big tables, albeit cumbersome, hold the value of enabling relatively quick glances (and sorting) of data to keep tabs on what's going on, as opposed to other more serious data reporting options and statistical tools; so I'm stuck with big giant tables.)

[Mottie]

Ok this should be fixed in the latest version (v2.3.3)... I tested it on the table you sent me, but with 270 rows and 260 columns with no error. Please double check it for me :)

[streetLAMP]

Using Chrome, I'm still seeing the same error, with the same hanging result. I've tried it with version 2.3.4, both locally and also pulling from your files online. I see the error only in Chrome (Chrome says it "is up to date" with version 19.0.1084.46 m) on a PC Win7, 64bit OS (but Chrome is running the default version, most likely 32 bit). I see the error in testing the 264 sample I sent you, but it works fine using the 250 row sample. I cleared cache, repeated, w/o any change in effect.

If you're able to put up another update, I'll be sure to get a same day test response back to you. (my weekends are less predictable).

Here's the error message, from Chrome's Console:
Uncaught RangeError: Maximum call stack size exceeded
s
c.querySelectorAll.m
f.fn.extend.find
b.tablesorter.addWidget.format
applyWidget
$.extend.tablesorter.construct
e.extend.each
e.fn.e.each
$.extend.tablesorter.construct
(anonymous function)
f.Callbacks.o
f.Callbacks.p.fireWith
e.extend.ready
c.addEventListener.B

[Mottie]

Hmm, ok I got it working by removing this css:

    TABLE.displayNone, .displayNone
    {
        display: none;
    }

I guess I need to add code to show the table before processing...

[streetLAMP]

Okay, when I remove the "displayNone" class, I am able to replicate the 264 row table as working in Chrome. Looking at the console though still shows the "Uncaught RangeError: Maximum call stack size exceeded" message.

Being able to hide the table upon page load, then build it within the pagesorter, and only then display it for the very first time enabled the page display time to be 2x-3x faster (for a table with, err, like 6,000 rows, which I have) as compared to first rendering the entire 6,000 row table and then applying the jQuery pagesorter widget and re-rendering it. Browsers don't like 6,000 row tables, and the pagesorter offers a nifty way of feeding a manageable view of the table to the browser.

Uncaught RangeError: Maximum call stack size exceeded
s
c.querySelectorAll.m
f.fn.extend.find
b.tablesorter.addWidget.format
applyWidget
$.extend.tablesorter.construct
e.extend.each
e.fn.e.each
$.extend.tablesorter.construct
(anonymous function)
f.Callbacks.o
f.Callbacks.p.fireWith
e.extend.ready
c.addEventListener.B

[Mottie]

The problem now is the columns widget.... I'll work on optimizing it to prevent that error.

[streetLAMP]

Sweet! That sounds like progress!

[streetLAMP]

What are your thoughts regarding eta of a fix for this issue?

[Mottie]

Well, I had it all fixed... then I tested it in IE7.... maybe this weekend?

[streetLAMP]

Ok - thanks. Appreciate your work, and the update on potential timing. May the force be with you.