Bug #5420
closed
[Workbench] Checkbox selections in collections page is wrong when using back button
Added by Radhika Chippada over 9 years ago.
Updated over 9 years ago.
Assigned To:
Radhika Chippada
Description
- Go to "/collections" page
- Select one or more collections; let's say you selected collection 1 and 2
- Use the Selection drop down and click on "create a new collection"
- New collection combining the selected collections is created and you will be transitioned to the new collection
- You will see that the new collection is listed at the top of the page and the selections are out of place by one. That is, collections 1 and 2 from the newest list are selected, not the previous two selections
- Observed this in Chrome and Safari, but not in Firefox.
- Description updated (diff)
- Category set to Workbench
- Target version changed from Bug Triage to 2015-04-01 sprint
Hopefully we just need to add a unique id
to each checkbox, so the browser doesn't have to assume the "first two checkboxes" mean the same thing after reloading a page.
- Assigned To set to Radhika Chippada
- Status changed from New to In Progress
Implementation notes:
- Adding id to checkboxes resolved the issue in /collections page (verified before and after using Chrome)
- Adding id alone did not help with the collection#show page. I also needed to added autocomplete="off" for the checkboxes as well as for the search box in this page. Here is the explanation: using Safari (and probably Chrome), access https://workbench.4xphq.arvadosapi.com/collections/4xphq-4zz18-gbv4fbtq6sdvzpd . You will see 3 files in this collection. Type “md5sum” in the search box. You will see two files. Select them and click on Selection -> create new collection… . Once you are in the new collection page, hit back button. You will now see all three files (all the files in this collection); however, the search box still has the text “md5sum” in it and the two md5sum files are selected. That is, the collection page is reloaded, but Safari is caching selections. I hence needed to add autocomplete off for the search box as well as for the checkboxes in this page.
- Verified using manual testing using Chrome in my VM.
Radhika Chippada wrote:
Implementation notes:
- Adding id to checkboxes resolved the issue in /collections page (verified before and after using Chrome)
This part looks good, thanks.
- Adding id alone did not help with the collection#show page. I also needed to added autocomplete="off" for the checkboxes as well as for the search box in this page. Here is the explanation: using Safari (and probably Chrome), access https://workbench.4xphq.arvadosapi.com/collections/4xphq-4zz18-gbv4fbtq6sdvzpd . You will see 3 files in this collection. Type “md5sum” in the search box. You will see two files. Select them and click on Selection -> create new collection… . Once you are in the new collection page, hit back button. You will now see all three files (all the files in this collection); however, the search box still has the text “md5sum” in it and the two md5sum files are selected. That is, the collection page is reloaded, but Safari is caching selections. I hence needed to add autocomplete off for the search box as well as for the checkboxes in this page.
I'm not so sure the page is being reloaded. It seems like another possibility is that our filtering JavaScript isn't being triggered when the browser loads the page with text already in the search box. Turning autocomplete off seems like a net UX loss to me: it seems likely that users will want to repeat searches, and browsers should be able to help them with that.
I also don't think it's a bug if the browser remembers what checkboxes are selected, as long as the selections refer to the same objects as users browse back and forth. The "before" behavior you describe sounds like it's okay except for the fact that the search filter isn't being applied. I think it would be nicer to fix that issue in the JavaScript, rather than artificially limit the form to prevent it from happening.
Thanks.
Brett said:
I'm not so sure the page is being reloaded.
I verified by looking at workbench and api server logs that the page is indeed reloaded.
It seems like another possibility is that our filtering JavaScript isn't being triggered when the browser loads the page with text already in the search box. Turning autocomplete off seems like a net UX loss to me: it seems likely that users will want to repeat searches, and browsers should be able to help them with that.
I reverted the search (as well as the checkbox) autocomplete off and created a separate issue #5620 to address this specific issue preferably to trigger search filtering on using back button.
I also don't think it's a bug if the browser remembers what checkboxes are selected, as long as the selections refer to the same objects as users browse back and forth. The "before" behavior you describe sounds like it's okay except for the fact that the search filter isn't being applied. I think it would be nicer to fix that issue in the JavaScript, rather than artificially limit the form to prevent it from happening.
The checkbox selections are correct (since no new files added etc). Since we are not clearing search box text + they are correct selections, it does not seem appropriate to clear selections alone. Thus, I reverted this update as well.
- Status changed from In Progress to Resolved
Applied in changeset arvados|commit:5781ff2dc48f95b7554259e0210272e7de2d883b.
Also available in: Atom
PDF