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.

We can add an event handler to make subsequent clicks a no-op before it posts the message

The down-side is that the forum submission will stop working for folks who disable JavaScript.

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 ;).

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.

The down-side is that the forum submission will stop working for folks who disable JavaScript.

Why? If JavaScript is not enabled, the form works like forms always have and we do get a duplicate forum post. Not much you can do about it.

Using JavaScript to prevent submission of the form on dual single clicks or a double-click is just a progressive enhancement.

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.

Thoughts?

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.

Edit:

If JavaScript is not enabled, the form works like forms always have and we do get a duplicate forum post. Not much you can do about it.

That turns out to be the case with my current approach. My over-engineered first attempt would have moved the submit part into JS.

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.

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.