tableresponsive.js causes huge page load time for extensions page

Thanks for reporting, issues need to be in MRs against 11.x

Probably need some profiling to be included, or a performance test.

The steps to reproduce in the issue summary are sufficient for profiling.

Unless this information is included in the chrome performance log, which I don't think it is, it would not be possible to add performance test support for it, and we definitely don't have that available now so shouldn't block a fix anyway.

So just some profiling numbers to the ticket then should work.

Ok. I identified the problem from profiling so that should be no problem at all. I'll add this in a little while.

Oh, I've been reminded why I didn't add an 11.x branch: When I click on the "Create new branch" above (https://git.drupalcode.org/issue/drupal-3521884/-/branches/new?branch_na...), it's a 404 for me.

Here are screenshots without the patch:

and with it:

For the 404 on creating a new branch - are you definitely logged into gitlab? Sometimes d.o and gitlab sessions go out of sync.

Thanks, I wasn't aware of that.

For anyone else searching for a solution in future, I could tell I wasn't logged into Gitlab by going to https://git.drupalcode.org/. In the top right corner, it had a 'Sign in' link. I was already signed in on D.O so just needed to click that button. It then showed my profile and the sign in button disappeared.

The patch applies without modification to 11.x-dev. A branch has been created and pushed and profiling screenshots supplied above; resetting to needs review in the belief that I've done everything that was wanted.

Can you open the MR for the tests to run please

Actually just did it real quick

Profiling looks good. MR shows there are eslint that needs to be addressed

Left 1 comment in the MR

Hmm, a test fails but it seems to be unrelated:

https://git.drupalcode.org/issue/drupal-3521884/-/jobs/5128162

The very minimum is to move the .trigger(resize) code out of the tableresponsive constructor. Add that after the once() in the attach behavior and it should mostly fix the problems of runaway initializations. We can also add a debounce to prevent too many calls to that function. The resize event is explicitly mentioned on the debounce script as a valid use case :)

I wonder how much this will help when you have test module discovery on.

Feel free, _nod.

I have to admit I'm not following what you're thinking so it might be better if you just go ahead and implement it.

updated the code, can you check it solves the problem?