4.2.6 loses checkboxes on some views.

I'm on Drupal 11 and have 4.3.3 with a view that provides a page and a block.

On the page, all checkboxes are available.

On the block, the checkboxes in the rows of the body are missing while the checkbox in the header is present.

This happens regardless of the used theme, I've tested both the current versions of Claro and Gin.

The markup of the table cell where we expect the checkbox is just empty:

<td class="views-field views-field-views-bulk-operations-bulk-form">

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->

<!-- END OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->

</td>

Any idea what could be causing this?

I found the reason for the problem but not the solution yet. Here goes:

The ViewsBulkOperationsBulkForm has an injected dependency for the ViewsbulkOperationsViewDataInterface. It calls the init function on that service once.

The problem is, services are singletons, i.e. if we have more than 1 view on a page, we have 2 bulk forms and both init the service with their view. When we later get to viewsForm this may operate on the wrong view being set in the service.

I guess we have to init the service more closer to the usage of the service, i.e. right before the service is being used.

I'll look if I can come up with a proposal.

Yep, that was it. I've created an MR which solves the issue. But I'm not sure if that's the best approach.

The solution is a performance killer. We rather need to save data as specific to view/display ID on init and then use the right data set when calling the remaining methods.

Good find though, thank you and hope you'll have some more time to follow-up.

I'm sorry, I can't fix that beyond this point. It seems that the architecture is just not correct to use a service here, as services are singletons and should not hold stateful data as that can always be overridden by other objects using the same service.

Maybe you need to pass the 3 arguments (view, display, relationship) with every function call to that service? Just guessing, but to make a good decision here, one would have to know the overall structure much better than I do.

Yes, that's what I had in mind, just more simple to use one argument: string [view_id]:[display_id].
This issue will be unsolved for a very long time then from my experience and your MR will have to be re-rolled multiple times as it's a very edge case and I have other more important projects on my plate. I guess that's fine though. Thanks!

Oh, you really believe that multiple blocks with views on a page is an edge case??? I'd just assume the opposite, it's the most common thing to do these days.