[JENKINS-68426] Jenkins runs many builds if mouse hardware failure causes multiple clicks.

[timja]

Bug Description

The Build Now on left side toolbar

and Build button in Build with Parameters.

Both have the same problem.
The launched Job from mouse hardware failure's multiple clicks will always complete.
This occur on multi-branch pipeline with build parameter and simple single pipeline with only echo 'Hello World' stage without any parameters.

Step to reproduce

1. You need AutoHotkey to simulate mouse hardware failure. Please install from here https://www.autohotkey.com/
   • create hotkey script with extension .ahk
   • copy following script
     autohotkey

     F4::
     Click 3
     

   • right click on your .ahk script and choose Run Script
     
2. Hover your mouse over build button and press F4 it will simulate mouse click 3 times consecutively.
3. You should see following result
   

---

Originally reported by bobo_sm, imported from: Jenkins runs many builds if mouse hardware failure causes multiple clicks.

• status: Open
• priority: Minor
• resolution: Unresolved
• imported: 2022/01/10

[timja]

JIRAUSER144133:

I'm still not sure about bug priority. 

[timja]

markewaite:

As far as I understand it, that is not a bug. That is the intended behavior. If a user clicks three times to launch a Pipeline job, the job should be run three times.

[timja]

ianw:

On the face of it sounds like "not a bug", but is it a case of protecting the user from themselves? It's easy enough to inadvertently double-click instead of single.

Are there any circumstances where a user would legitimately instanatiously and sequentially manually launch multiple instances of the same job? I think it's not likely. I launch 600+ different jobs simultaneously, but only one instance of each, or the same one multiple times, but with different parameters, never the same.

Is there merit in preventing multiple manual executions within x/10ths of a sec of the same job?

[timja]

markewaite:

Thanks for the observation ianw.

My personal opinion is that any "keyboard debounce" (or "mouse debounce") logic that would be placed into Jenkins would cause more harm than the benefit it was trying to provide. Command line calls to start a job may happen very quickly and be exactly what was intended.

There is a form of "debounce" in parameterized freestyle jobs so that by default a parameterized job will not be started with the same parameters as were used in a currently running or currently queued job. There is an option to disable that feature in freestyle jobs. Pipeline jobs do not have that debounce technique as far as I can tell.

[timja]

JIRAUSER144133:

Let me explain using Model-View-Controller pattern here.

If there is any code change, Ideally, It should be on WebUI, The Input Controller Module.

It's possible to do it on Jenkins Core Model but you need more parameters to distinguish WebUI request.
This couple implementation from Controller into Model and it increases code-base maintenances cost.

I'm not sure how hard it is to implement HTML5 JavaScript on WebUI to prevent this.