On configure form every entity is selected when user didn't select anything

I have been able to replicate this bug on version 4.3.1.

In our instance, we had custom functionality that added a hidden element to the Views Exposed Form that was unique for each new form build.

Here is the workflow of the cause of the bug:

1. When the VBO form was submitted again after returning via the browser back button, the exposed form input had changed, triggering $this->tempStoreData['list'] to be cleared in ViewsBulkOperationsBulkForm::updateTempstoreData().
2. Then in ViewsBulkOperationsBulkForm::viewsFormSubmit() because the selected key was not in $this->tempStoreData['bulk_form_keys'] nothing got re-added to $this->tempStoreData['list'].
3. Then finally in ViewsBulkOperationsActionProcessor::executeProcessing() because $data['list'] is empty it gets set to all view results and ALL view results get processed!!

If we removed the custom hidden element, the bug didn't occur.

Even though it is a specific set of circumstances that would trigger the bug, I feel it is a critical issue given that data loss (e.g. with delete node action) or security issues (e.g. with unblock users action) could occur.

I have been able to create a FunctionalJavascript test locally but it requires the browser to be in non headless mode. Not sure if it will work with Gitlab CI but I will add a MR for this test shortly.

So it took some fiddling with the chrome options to get back/forward cache working but the test is now failing as expected.

https://git.drupalcode.org/issue/views_bulk_operations-3199534/-/pipelin...

I will take a look at the patch from #2 tomorrow and create a MR with a potential fix.

I have added MR !91. This was inspired by on_configure_form_every_entity_is_selected-3199534-02.patch and although it doesn't specifically fix the bug, it prevents the bug from causing unexpected data changes by throwing a validation error when the bug conditions occur.

The problem with patch #2, apart from needing to be modified to apply to updated code, is it just displays the error message No items selected.. After getting the error, if the user continuously selects options without reloading the page, the same error message will keep appearing. So I updated the error message to provide a link to reload the page , along with helpful info to prevent the problem form occurring in the first place.

Ideally the code needs to be modified to correctly handle back/forward cache, but I believe that is best served in another issue as it is more complex and will most likely need greater input from @graber.

Updated the MR to add a a pageshow event listener which will prevent the bug from occurring in the first place. As suggested on https://web.dev/articles/bfcache.

I still think it is worth the extra measure to keep the validation and sanity check in place "just in case".