Oddity: Double-post for double-click
(1) By Larry Brasfield (larrybr) on 2023-10-24 17:59:00 [source]
(2) By Stephan Beal (stephan) on 2023-10-24 18:09:03 in reply to 1 [link] [source]
I submit that this might be counted as a bug.
It is. We can add an event handler to make subsequent clicks a no-op before it posts the message - i'll look into that tonight or tomorrow. It's been my experience (admittedly a decade or more ago) that simply disabling the button on the first click is not reliable - the second click may get through before the disable takes place (that might not still be the case, but it was 10+ years ago). We might (might) want to try to defend against that case (somehow) in fossil itself.
(3) By Stephan Beal (stephan) on 2023-10-24 18:34:24 in reply to 2 [link] [source]
We can add an event handler to make subsequent clicks a no-op before it posts the message
Though i personally don't feel the need to support no-JS clients, there will be some fraction of users who would cry out about that change if they could post their frustrations from their no-JS environments ;).
(4) By Larry Brasfield (larrybr) on 2023-10-24 19:01:23 in reply to 3 [link] [source]
Maybe just handling double-click events would do it. I do not recall having to specially process single-clicks in any other GUI environment.
I would expect a timestamp to accompany the events if applications are expected to distinguish bona fide single-clicks from double-click.
(5) By John Rouillard (rouilj) on 2023-10-24 19:28:28 in reply to 3 [link] [source]
I think this works:
on click, check the variable has_submitted if true, notify user to be patient (8-)), prevent default and stop propagation if false, set has_submitted=true, disable the button and return letting the default action and propagation occur as normal on dblclick trigger prevent default and stop propagation effectively throwing away the double-click.
(6.1) By Stephan Beal (stephan) on 2023-10-24 20:02:20 edited from 6.0 in reply to 5 [link] [source]
dblclick ... Thoughts?
Way back when i first had to work around this problem, dblclick was not a standardized thing so i simply didn't consider it. It seems to be widespread now, so simply discarding dblclick would seem like the easiest approach. It's not working, however: the submit triggers at the moment of the first click, before the dblclick is registered.
i've got a workaround in place and am testing it. It seems to work but is painfully kludgy so i'd like to sleep on it one night before checking it in.
In short: if we disable the submit button as part of the "submit" event then that button's name and value are not included in the form's POST data, but the server-side code requires that they are. One workaround is to disable the button and inject a hidden element with the same name and value as the button, which causes that hidden element's name/value to be POSTed and keeps the server-side parts working as is.
That turns out to be the case with my current approach. My over-engineered first attempt would have moved the submit part into JS.
(8) By John Rouillard (rouilj) on 2023-10-24 22:03:45 in reply to 6.1 [link] [source]
Try disabling the button in a setTimeout of 0. That will force it to run in the next event cycle which is after the form submission is done.
(7) By Stephan Beal (stephan) on 2023-10-24 20:29:52 in reply to 1 [link] [source]
As visible here, if one double-clicks on the "Submit" button...
That should be fixed in src:600f171306d29f39. As copy/pasted from /chat:
That is difficult to test because my browser (FF on Linux) does not even get the 2nd half of a double-click before the first submits the form, but this approach is minimal and "should" work on browsers which can actually trigger it. When any SUBMIT button is pressed, the parent form records that a submit has been pressed and continues with the submit. If a second SUBMIT event arrives, it's discarded. The only way i can get my browser to actually get that 2nd click to the button before the submit happens is to programmatically send it a click event via the dev console. That works, though, so it will presumably also work if a user slips in a second click.