checkboxes lose state if confirmation screen is enabled and user cancels or uses back button
| Project: | Views Bulk Operations (VBO) |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | kratib |
| Status: | closed |
Jump to:
I'm not sure if anything can be done about this, but...
If the confirmation screen is required and a user goes through a big long list and checks off some of the items, selects an operation, and then clicks the cancel link (or uses the browser back button) the checkboxes that they selected are no longer active.
Ideally it should remember the items checked.
This issue is present in Drupal core as well - #358961: checkboxes lose state if action requires a confirmation screen and user cancels or uses back button but I thought I would submit it here since VBO is the future of bulk operations in Drupal (at least in my opinion).
So, this may not be easily solved in Views Bulk Operations itself. One interesting note: the problem goes away if the user uses the back button and JavaScript is disabled.

#1
Yes, that's one area where VBO is lacking. I've been thinking about a solution to preserve state across pages, but nothing concrete yet.
#2
#3
The latest 6.x-1.x-dev contains a fix for this issue. The selected nodes and operation are persisted in a SESSION variable so that clicking the Back button or the Cancel links re-loads the user's choices. Tested to work on FF3/Linux, FF3/Windows, IE{8,7,6}/Windows, Safari 3.2/Windows. Back button NOT supported on Opera. Haven't tested on Mac browsers. Please try it and let me know (after the obligatory 12 hours or pull directly from DRUPAL--6-1).
#4
I downloaded the latest code from the DRUPAL-6--1 branch via cvs and tested this out with Firefox, Camino, and Safari (on mac). When I click either the back button or the cancel link and go back all of the checkboxes on the page are selected.
Did you ever see that?
What can I do to help debug this?
#5
Good catch! I'd changed the code around before the last commit and that introduced a regression. Should be fixed now.
#6
Yes, in my initial tests this seems to work perfectly. Thanks!
#7
Automatically closed -- issue fixed for 2 weeks with no activity.