#28889 closed Cleanup/optimization (wontfix)
Use JavaScript to prevent double submission of admin forms
Reported by: | Manuel Saelices | Owned by: | Marcelo Galigniana |
---|---|---|---|
Component: | contrib.admin | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
For fast clickers.
Change History (19)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
comment:2 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I think this is an improvement and the implementation looks reasonable.
comment:3 by , 7 years ago
Has patch: | set |
---|---|
Needs tests: | set |
Summary: | Prevent double submission on admin forms → Use JavaScript to prevent double submission of admin forms |
Type: | Bug → Cleanup/optimization |
I found an article titled JavaScript: Preventing Double Form Submission which might be worth reviewing. In particular, it points out "Rather than simply disabling the button, we can also change the text so that people don't get confused."
Did you consider trying to add some tests for the patch?
I share Nick's concern on the pull request that this may have a good chance of causing some regression in unconsidered edge cases. I'm not sure if it's considered a best practice these days. The article suggests that some browsers (e.g. IE11) treat a double click as a single click. It seems unfortunate if every project has to add something like this.
comment:4 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 7 years ago
Hi Karan,
Thanks for the input. Your fix includes the changes Nick suggested from the original PR. (Great.)
To get this merged we need to address Tim's concerns.
- Can we add some selenium tests, to exercise the behaviour?
- What's your assessment of the article Tim linked to? Do we need (still) to do this?
comment:7 by , 7 years ago
Hi Carlton,
- I am unable to reproduce the behavior, probably because till now, I am serving on localhost.
- In the article, there are different methods of implementing the same. One improvement can be changing the label of the submit button after a click.
- From the point of usability, there is just a comment by someone, which also doesn't seem concrete.
Please guide me on how to proceed further.
comment:8 by , 3 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:9 by , 3 years ago
Has patch: | unset |
---|---|
Owner: | set to |
Status: | new → assigned |
comment:10 by , 3 years ago
Has patch: | set |
---|---|
Needs tests: | unset |
comment:11 by , 3 years ago
Patch needs improvement: | set |
---|
comment:13 by , 3 years ago
I think thibaudcolas's comment in 1st approach makes sense: https://github.com/django/django/pull/15217#issuecomment-1018935149
So I updated the PR to go for the first option
comment:14 by , 3 years ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
comment:18 by , 2 years ago
Has patch: | unset |
---|---|
Resolution: | fixed → wontfix |
Triage Stage: | Ready for checkin → Unreviewed |
Patch was reverted, it's probably not worth complexity.
comment:19 by , 4 months ago
In our production environment, we encountered this issue with inlines. Adding an inline object and mistakenly clicking “Save” multiple times resulted in multiple requests, leading to the insertion of the same inline object multiple times. To resolve this, I disabled the buttons on form submission by overriding admin/submit_line.html
as follows:
{% extends "admin/submit_line.html" %} {% block submit-row %} <script> if (!$){ const $ = django.jQuery; } $(document).ready(function() { $('form').on('submit', function(event) { $('input[type="submit"], button').prop('disabled', true); }); }); </script> {{ block.super }} {% endblock %}
I understand the concerns raised in previous discussions about network failures potentially leaving buttons disabled and preventing further user actions. However, I believe we need to weigh which scenario is worse: adding duplicate entries or requiring users to re-enter their changes. Additionally, we should consider which is more likely: mistakenly clicking “Save” twice or experiencing a network failure. IMHO, it might be good to address this issue to enhance the user experience and data integrity.
Fixed on this Pull Request: https://github.com/django/django/pull/9425