Bug #23009
closedMultiselect becomes inconsistent after searching large project
Description
Seen with Workbench v3.2.0~dev20250625201747. Steps to reproduce:
- Go to a large listing. I'm not sure how large it has to be—I suspect it's more than one page. I'm using "Shared with me" on tordo.
- In the upper right, do a search to filter the results.
- Press the Select All checkbox in the upper left.
Some items are selected, but at some point in the listing it cuts off and stops. All visible items should be selected.
It gets weirder. Picking up where we left off:
- Press the Select All checkbox again to unselect everything.
- In the upper right, clear your filter to see the full listing again.
- Press the Select All checkbox again.
It only selects items that matched your filter, not everything on the page.
In general, it feels like every filter that ever applies to the listing is remembered and used by Select All. It remembers what's on the first page of results, so when you add a search filter, then Select All, it only selects what was on the first page. Then when you clear the search filter, and Select All again, it only selects what was on the first page+matched the filter. What Select All selects needs to be kept consistent with what's visible on the page.
Updated by Brett Smith 9 months ago
- Target version set to Development 2025-07-23
- Assigned To set to Stephen Smith
Updated by Brett Smith 8 months ago
- Target version changed from Development 2025-07-23 to Development 2025-08-06
Updated by Stephen Smith 8 months ago
Changes at arvados|8935055f9ac5ac828e8ae1ccddae9abee025929e branch 23009-multiselect-bug
Tests developer-run-tests-services-workbench2: #1557
- All agreed upon points are implemented / addressed.
- Changed multiselect initialization to initialize even when checkedlist is not empty - since we don't seem to avoid resetting the selection I don't see any reason to preserve the existing checked state
- I also changed a few functions to simplify them with declarative alternatives instead of using loops
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- none
- Code is tested and passing, both automated and manual, what manual testing was done is described
- added tests for "filter, check, clear filter, select all"
- Documentation has been updated.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- no change
- Considered backwards and forwards compatibility issues between client and server.
- none
- Follows our coding standards and GUI style guidelines.
- yes
Updated by Brett Smith 8 months ago
- Target version changed from Development 2025-08-06 to Development 2025-08-21
Updated by Lucas Di Pentima 8 months ago
Both reported issues have been fixed, but only the select-after-search issue is being tested.
I guess both bad behaviors are related and belong to the same bug, and if that's the case, this LGTM.
Updated by Stephen Smith 8 months ago
- Status changed from In Progress to Resolved
It should be fine since it's another way to elicit the same bug, just in the other direction (unfiltered -> filtered)