Material-table: Browser Freezes in Version 1.69.0 on material table render

[kumarunster]

We noticed strange freezes in our application, which we were able to trace back to Material Table.

The freeze is caused by the new introduced function `reducePercentsInCalc' from PR #2351

the calc parameter is growing exponentially, so that the indexOf call takes huge amount of time on that large string.

Here couple of screenshots form the cpu profiler.

further analysis makes me sure, that the really cause for that input parameter growing is following code in data-manager.js

in my opinion the undefinedWidthColumns is missing check for tableData.width, which is assigned few lines later, once the column gets rendered.

this is the possible cause for already reported bugs #2451 and #2453

@Domino987, @mbrn what is your thought about that?

[Domino987]

Hi thank you for the detailed evaluation . This problem is known and there is at least one PR to address this, but since we cannot get hold of mbrn since weeks, I do not know when this can be merged. Reverting back to 1.68 removes the Problem, until this is solved.

[kumarunster]

@Domino987 thanks for quick reply. Could you point me to that PR? In my opinion the fix should be in data-manager#getColumns, not in common-values#reducePercentsInCalc.

[RobertGardner]

I believe the problem is in (perhaps "also in") data-manager#setColumns.

At the top of that method it finds all the columns that do not have defined widths, using:

columns.filter(function (c) {
   return c.width === undefined && !c.hidden;
});

It then proceeds to calculate a width and assign it to columnDef.tableData.width.

When setColumns gets called again (which happens frequently), it doesn't recognize that the column width has now been set for those columns because it is only checking c.width. So it recalculates but builds the new width based on the old columnDef.tableData.width. So columnDef.tableData.width keeps growing indefinitely.

It seems like the correct fix is to change the check at the top of setColumns to be:

columns.filter(function (c) {
   return c.width === undefined && c.columnDef.tableData?.width === undefined && !c.hidden;
});

[gxtaillon]

Likely related are #2451, #2418, #2404

[kumarunster]

Thanks @gxtaillon for linking the issues.

Any news from @mbrn? I hope he is well.

[kumarunster]

@mbrn any plans on this? Do you want a PR?

[Domino987]

It's already done. A quick fix with 1.69.1 was released of #2423 and a deep fix which is not merged yet of #2510 . Thank you though for the help.

[kumarunster]

@Domino987 thanks for linking PR's here. As mentioned above, it does not fix the main issue. Main issue is in the data-manager.js. @RobertGardner provided a proposal for that, which should fix everything on the source. Please take it into account. Then the reducePercentsInCalcwill run fast and safe.

[Domino987]

@kumarunster I added the above mentioned fix as well

[kumarunster]

@Domino987 thanks

[kvskranthikumar]

I can still see the issue with the latest version 1.69.2
Here is the sample to recreate this issue -

https://codesandbox.io/s/compassionate-meitner-802l6

Just clicking on the rows hangs the browser.

[kvskranthikumar]

@mbrn, any updates on this issue?
Due to this, we can't upgrade the material-table version to the latest version.

Here is the sample to recreate this issue -
https://codesandbox.io/s/compassionate-meitner-802l6

Just clicking around 10 to 15 times on the rows hangs the browser.

[yhaelopez]

Any updates on this? I'm having the same issue.

[peacechen]

@RobertGardner
Thanks for the insight into the width calculations growing infinitely. The root problem is a logic error in the order of operations. See PR #2689