Thursday, September 30, 2010

Preventing double submit on multi button forms with jquery

Note that this is just a fast feedback mechanism, it shouldn't replace server side logic to prevent double submits. This is specially true if the operations can’t be easily reverted or there would be associated costs to reversing the operation.

With that out of the way, lets get right to the code:

   1: $(document).ready(function () {
   2:     $('form').submit(function (e) {
   3:         var theForm = $(this);
   4:         var isValid = doSomeFormValidations(theForm);
   5:         if (!isValid) return false;
   6:         setTimeout(function () {
   7:             var btn = theForm.find('input[type="submit"]');
   8:             btn.attr('disabled', 'disabled');
   9:             btn.val('Processing');
  10:          }, 10);
  11:         return true;
  12:     });
  13: });

Replace doSomeFormValidations with your own logic and you are good to go. There are other alternatives you might already be using, like having the button disabled until all validations passes. The important bit there is to make sure it’ll only disable the buttons if all validations passed.

Now lets go over some pieces and why those are relevant to it working with multi button forms.

  • return true/false in the submit body: true moves forward with the submit, while false cancels it. 

    • An alternative to this is returning false, unbinding our submit function and explicitly calling theForm.submit(). While this seems to work in the multiple button scenario, we are playing with fire here. We are relying on jquery or the underlying browser events/functions to send that last clicked button’s value. This is an implicit assumption we would be making, and it's usually based on works on my machine.

  • Disabling the submit buttons & adding a processing message for the user: 

    • No delay: has the undesired side effect that the button’s value isn't sent with the request in some browsers. Additionally it can even prevent the submit if it were disabled on the button’s click instead of the form’s submit. This is not totally unexpected as we are disabling the button. In fact, disabling any other input element (textboxes, select, etc.) can cause that data not to be sent to the server just like with our selected button’s value. 
    • Delay: By adding an insignificant delay, we let the rest of the submit behavior do its thing, so all the values in the form are sent in the request, including the selected button’s value. After those values are grabbed by the submit, we can disable controls and change values without affecting what will be sent to the server.

  • Don’t call use an id/name of ‘submit’ in your buttons. While not shown in the above code, this is important as it could cause conflicts with the submit events.

I want to stress out what I just mentioned in the no delay bullet. Just disabling any input of the form right away, will prevent the value from being sent to the server in some browsers.

This can easily get you into a situation where you can't figure out why the button pressed isn't being sent to the server, specially if you are working on an already built third party site. So if you are missing any input, first use a developer tool to inspect the elements and then go through the scripts, it's very likely somewhere in there.

You can tweak the above function to fit your needs, like display a different message, hide part of the UI, take actions if it'll timeout.

2 comments:

  1. Why 10 millis timeout? You can set it to 0 and it will fire right after submit code (and default submit handler) will be executed, but not before due to single-threaded model of JS

    ReplyDelete
  2. @1nd1go that's right, I'd really expect it to work with it set to 0 just like you said.

    The key piece is to let the submit grab all the values before the additionally code does anything to those / like disabling the buttons.

    I can't go back to the multiple browsers and confirm it, but 10 ms was low enough that at least one of the various scenarios we tried must have behaved just like that - waiting until the submit call was done.

    ReplyDelete