Bug 242314 – Double clicking submit button causes forms to be submitted twice

• Component: Forms
• Status: NEW

[Neil]

Fill out a form (ether GET or POST), press submit, and the results are sent to the server.  But if you double-click the submit button (as many people do), two separate requests are sent.  This simple bug is the source of a vast number of hard to reproduce glitches:
* doubled posts being submitted to forums.
* server-side race conditions which have caused data loss (even code written for a single user needs to be thread-safe).
* one-time actions that quietly succeed (first click) but a failure message is displayed to user (second click).
* add one thingmy to your shopping cart, get two.  Remove one, lose both.  (Great if you want pairs of everything.)
* order your two thingmys, and four arrive in the mail (along with two invoices).
Because of this bug, every form that performs an action needs to be wrapped in a JavaScript double-click trap, or else caught server-side (which involves logging requests and checking the log for a similar request in the past second).


Reproducible: Always

Steps to Reproduce:
Point Safari or Chrome at a form.  In a terminal window, "tail --follow access.log".  Double click (or triple click) the submit button.

Actual Results:  
Webkit browsers will submit the form as many times as the mouse was clicked.

Expected Results:  
Webkit browsers should not submit a form a second time within the double-click time frame.  Webkit browsers perform properly on links; double-clicking a link does not generate two requests.

Interestingly, I filed this exact bug against Mozilla 19 years ago (#238159).  At the time, Mozilla was the only browser exhibiting this bug, IE 5, Opera 7, and Netscape 4 were not affected.  Now that Mozilla has finally been fixed, Webkit has started doing the same thing.

[Alexey Proskuryakov]

I wonder if Firefox violates the spec now.

[Karl Dubost]

First, GET and POST are different. 

An HTTP GET is idempotent (to be used only for safe operations), so you could send as many times as you want, it should not create an issue. It's why it is always recommended to never use GET for something which requires a POST. 
see https://www.w3.org/2001/tag/doc/whenToUseGet.html


Neil, do you have a reduced test case (or a specific website exhibiting the issue you are mentioning) for HTTP POST and double click to be sure we are talking about the same thing.


dblclick and click are also different events. 
* https://w3c.github.io/uievents/#event-type-dblclick
* https://w3c.github.io/uievents/#click

As for the Mozilla issue, the link to click 
https://bugzilla.mozilla.org/show_bug.cgi?id=238159

On the bugzilla issue you used as an example

0. Go to https://scotcrest.com/product/clan-single-malt-scotch-whisky-70cl/
1. Choose a Design
2. Select 18 years old checkbox
2. double-click on "Add to Basket"

Firefox adds 1 item
Safari adds 1 item.


Logging dblclick and click

[Log] "click" (fbevents.js, line 24)
[Log] "click" (jquery.min.js, line 2, x4)
[Log] "click" (modules.eaa59710f7e60ac1d235.js, line 2, x3)
[Log] "click" (jquery-3.6.0.min.js, line 2)
[Log] "click" (fbevents.js, line 24)
[Log] "click" (jquery.min.js, line 2, x4)
[Log] "click" (modules.eaa59710f7e60ac1d235.js, line 2, x3)
[Log] "click" (jquery-3.6.0.min.js, line 2)

So maybe this site doesn't illustrate the issue anymore, maybe because of the dblclick  trap you are mentioning 


This test is currently failing for dblclick.
https://wpt.fyi/results/uievents/click/dblclick_event_mouse.html?label=master&label=experimental&aligned&q=dblclick


I need to dig further today on this.
But any very simple test case you are thinking about Neil would help. 
I will create my own with a local server today. Thanks.

[Karl Dubost]

Created attachment 460665 [details]
firefox, chrome, safari

This shows dblclick and click on a simple button, to make sure we are talking about the same thing. This works the same across the 3 browsers. 

Next test will be a input type="submit"
https://codepen.io/webcompat/pen/QWmjarq

[Karl Dubost]

Created attachment 460666 [details]
firefox, chrome, safari

This time the test is a <input type="submit">
https://codepen.io/webcompat/pen/YzayYBy?editors=1010

The outlier here is Firefox, which emits only a click event.


Firefox Nightly 104.0a1
Google Chrome Canary 105.0.5160.0
Safari 16.0

[Karl Dubost]

There are indeed a lot of techniques online to prevent this behavior. 
Example:
https://stackoverflow.com/questions/36767731/how-to-prevent-double-click-event-on-submit-button

https://duckduckgo.com/?q=prevent+double+click+event+on+submit+button&t=h_&ia=web

The HTML spec doesn't constraint the input type="submit"
https://html.spec.whatwg.org/multipage/input.html#submit-button-state-(type=submit)
And I didn't find an issue previously discussing it. 

Neil, is there an issue on the Chromium project?

[Karl Dubost]

ooh… I see you just got it fixed in Firefox. 
https://bugzilla.mozilla.org/show_bug.cgi?id=238159#c17

The Mozilla Webcompat team will be probably on the watch out with any regression. 
Probably to follow the results on https://webcompat.com/

[Karl Dubost]

Comment on attachment 460666 [details]
firefox, chrome, safari

ah no this is obsolete. 
https://codepen.io/webcompat/pen/YzayYBy

Sorry for the noise. Firefox behaves like Chrome and Safari and emits a dblclick.

[Karl Dubost]

Created attachment 460670 [details]
dblclick for input type submit test

[Neil]

Here's a video of the behaviour:  https://youtu.be/9k59Ze9b8m0

We start a test of POST on Safari:
* Single click on POST form -> single server fetch.
* Double click on POST form -> two server fetches.
* 10 clicks on POST form -> 10 server fetches.

This process repeats with a test of GET on Safari, and with a simple anchor on Safari, all with identical results.

All these tests (POST/GET/anchor) are repeated with Chrome, all with identical results.

All these tests are repeated with Firefox, but with different results: POST and GET form submissions are restricted to single server fetches, while simple anchors do fetch multiple times.  Note that the output of Firefox is slightly confused because it fetched favicon.ico once for each test group, thus polluting the log a bit.

The pages were on a remote server, and the destination page takes about 200 ms to load (the same test run locally behaves differently due to the speed of the fetch).

[Radar WebKit Bug Importer]

<rdar://problem/96821505>