Check *All* the possible cases of double-clicks on submit-ish buttons
Summary
Make sure that all the double clicks are disabled
Why
Because undesirable effects occur on many double-clicks
Details
Check all the buttons - make sure that double-clicks are disabled. If they aren't, either disable the double-click or raise an issue, if that's not plausible.
(If you can think of a good reason one shouldn't be, bring that to our attention, of course)
Note/ Background
Recently we found that the import csv on storage locations was double-clickable, with the result that the import could happen twice. With the result that the values were doubled. This is the kind of thing we want to avoid throughout,
Criteria for completion
- [ ] No button is double-clickable
- [ ] Tests to support
I'd like to take this issue on, thank you!
Sure!
I was wondering if the existing example I should use on all submit-ish buttons lives in the users/registrations/edit.html.erb file? I know it was mentioned the submit button in distributions somewhere, but I couldn’t find it. Here’s what I found in the registrations edit.html.erb file:
<%= _button_to({ text: "Save", icon: "floppy-o", type: "success", align: "pull-right" }, disabled: true) %>
with the respective test in the spec/system/account_system_spec.rb file:
expect(page).to have_button('Save', disabled: true)
I was wondering if otherwise I can use the disable_with feature turbo provides to disable the button and for it to have a little transition saying “processing” or “please wait…“. This means I would:
-
changing the form.submit to form.button in view pages
-
add span class show when enabled
-
add span class show when disabled
-
upon the second click, it will show “processing” or something like that
-
use css to hide and show the spans
-
use the same test to check if it works: expect(page).to have_button('Save', disabled: true)
-
Resource to this method is here at the 9:00 min mark
Would love to get input on which would be the best way forward for this. Thanks!!
If you're using disable_with, why do you need all the rest of it? Check something like this https://stackoverflow.com/a/76288769/5199431 - there should be a really easy way to accomplish this.
Hi there, I'd like to pick this up if its free?
I've been looking at the existing code to understand the scope:
app/helpers/ui_helper.rb has a submit_button that disables double-clicking with disable_with:
def submit_button(options = {}, data = {})
disable_text = options[:disable_text] || "Saving"
_button_to({ text: "Save", icon: "floppy-o", type: "success", align: "pull-right" }.merge(options), data: { disable_with: disable_text }.merge(data), name: options[:name] || 'button')
end
(btw in the hotwire cookbook presentation it's mentioned to use turbo_submits_with rather than disable_with, but maybe this project is on a slightly older version of turbo?)
Then I looked at how many forms are used across the project, which seems to be using simple_form_for (is this a safe assumption to make that all forms are built with simple_form_for) -> 59
Then searched for occurrences of submit_button helper -> 51
Is the scope of this task to find the 8 forms that aren't using the submit_button helper and convert them to use that?
For example, app/views/product_drives/_form.html.erb is not using the button helper, rather it has:
<%= f.button :submit, :class => 'diaper-drive-submit btn btn-primary', :id => 'product_drive_submit' %>
OR
Are there other kinds of buttons that don't occur within a form, and all those also need to be fixed as well?
Another thought: If there's a lot of forms to fix, the PR could get large, would it be useful to submit smaller, multiple PRs that fix one form at a time?
The background on this is that we had several cases where we were getting a lot of double-clicks that resulted in the same action affecting the database twice. So we're mostly concerned with things that have that potential -- There's no significant problem if someone pushes a "view" button twice, for example, or even an "Edit", "Deactivate" or "Restore" button, so those would be lower priority.
There might be an issue if someone double-clicks a "Delete". I would expect a problem as possible on any save, of course. I could see problems from any of the following if double-click is not blocked: "Fulfill Request", "Submit for Approval", "Approve", any of the buttons that say "Invite", "Request Recertification", "Transfer"... We should probably block it on regenerating the annual report -- though it would just slow it down, probably.
Note: Daniela is going to do #3990 first.