Missing tableselect dependency in view

This patch doesn't seem to add the "Select all" checkbox in the table header. Are there any other steps needed besides making sure all caches are freshly built?

Test coverage would be nice too.

Patch #2 works for me, this is the before:

and the after:

But I have had to add a label to the filed in the view, otherwise it doesn't show the header of the table.

I have added a test for it, the test just checks that the checkbox is present in the header table but not the behavior of it since that should be cover by views itself.

thanks @marcoscano !

Has been manually tested, automated tests are added (and green).. looks good to me.

Re-queued tests on #7 again.

I think we should get tests passing on 8.x-2.x as well, right?

Yup, should be fixed to have this RTBC for 8.x-2.x also. Correcting the version accordingly.

Hi, i tried patch from #7. And I added a label to the bulk field in views.
But it doesn't work for me. I'm still not able to select all the items in the table.
I'm on using 8.x 2.5 version. I also tried the other patch (from #2922313) trying to solve this but this also didn't work for me.

What can do I need to do to get this patch/function to work?

The change the jquery once library has made the patch in 7 not apply cleanly with the latest release. Here is a rebase of that patch.

Another rebase as patch wasn't applying cleanly to 8.x-2.9.

Edit: Actually, it may just be a conflict with the patch in https://www.drupal.org/node/2851580.

Working for me on 2.x and Tests are still passing, RTBC

Works fine in 8.x-2.9 and 9.5.5 core.

I'm curious why it's this module's responsibility to add that library and why it isn't included with the rendered View? Does this point to a Drupal core bug?

Up!

Needs to be converted to a merge request so that tests can run.

Opened a merge request based on patch #17.

@berdir: MR was created, but I agree #20 might be a fair point. What do you think?

I asked Claude Code about Dave Reid's question, and it said (emphasis added),

That's a fair question. It gets at the root cause vs. symptom distinction.

In standard Drupal, when you use #type => 'tableselect' in the Form API, the render element automatically attaches core/drupal.tableselect. So the library "just works" without anyone explicitly declaring it.

But that's not what's happening here. Entity Browser provides its own custom Views field plugin (entity_browser_select) that renders individual checkboxes/radios. It deliberately bypasses core's #tableselect form element — so the automatic library attachment never triggers. The "select all" checkbox in the <th> header only works if core/drupal.tableselect JS is present to wire it up, but nothing in this rendering path requests it.

So to Dave's question: not really a core bug. Core's contract is "if you use #tableselect, we attach the JS." Entity Browser chose a different rendering path (a Views field with manual checkboxes) — which is a reasonable choice for the Views integration — but that means the module takes on responsibility for declaring the dependency itself.

You could argue Views' table style plugin should attach core/drupal.tableselect whenever it renders a table with a select-all header, regardless of how the checkboxes got there. That would be a legitimate core feature request. But as things stand today, core isn't doing anything wrong — entity_browser is just operating outside the path where the library gets auto-included.

The fix on this branch is the right pragmatic solution.

Clean, minimal fix. The dependency was genuinely missing, the test validates the specific behavior, and the view config tweak is a reasonable supporting change. Looks good to merge.