[Prevent Spam Clicks] Countdown continues past 0

Forge Component
Published on 8 May by João Pedro Abreu
6 votes
Published on 8 May by João Pedro Abreu

There is a multi part form I have on a page. This consists of 3 forms with similar structures that save to different data. I use PreventSpamClicks to prevent duplicates being made from an overeager user. The save action is different for each save button and there is a PreventSpamClicks on each one.

When I click save on the first form, I may need to go back later to create or edit data. On going back after saving the data, the countdown appears to start at 0 on the ajax refresh and counts into the negative. Ideally it should stop editing the innerHTML of the button when lower than 0 rather than at 0.

Hi Dominic,

Is it really related to this component (Prevent Spam Clicks)? Have you tried not using it to see if the issue still happens?

Another thing: what are those counters and how are they updated? And what do you mean by "going back"? Is to click the back button in the browser?



Hello, thanks for the reply José, 

The countdown is an element of the prevent spam clicks, without it, the button countdown does not exist. 

I have tried not using it and implemented my own functionality which works in this specific case, but may not in others. Obviously the issue has passed using this method as there is no way for the value of the button to change.

The user can click a button to go display the previous form (go back) though it is on the same page. It is just like ajax refreshing the page after setting the style display:none in a few elements and removing that line from others.

On a full page refresh the element and jquery stops, so this could work with a regular submit, but I would really like this to work properly with ajax submit. 

I think it may be due to the fact there is no way currently to force the jquery to finish, so it probably sets the value to 0 (but still runs in the background) This can be seen by clicking the back button on the page (to reload the form) and seeing the original button text ("Save" in this case). This then quickly counts into the negatives.

I hope this information helps,


Hi Dominic,

Now I understood what you mean. And I also think that what is happening is what you describe in the last paragraph. 

One thing that you can do is to put the button (and the prevent click widget) outside of the elements that you are refreshing. That will make it work.

Is this something that you can also do in your screen?




Since each of the save buttons call a different server action, I would imagine this is not possible unless I do some magic with conditional statements and have a really complicated piece of logic with a dynamic server action and dynamic save button.

One other possibility is to have all parts of the form constantly visible. This would be a bit confusing to work with though and even though it was considered in early development, it is not something we would do now we understand how complicated it would end up being.

It is possible to move this button outside, but I would rather the issue be fixed than a work around be discovered. 

I do understand it may be a complicated issue that may not be able to be fixed, and I don't really mind if it isn't (since I already found my own work around), but ideally it should be looked into to expand the functionality of this simple but effective widget and prevent this issue happening for other people who use multi-part forms and data.