jQuery: modifying the submit button when a form is submitted

Posted on Friday, June 19th, 2009 | Filed under jQuery

I’ve found it useful on certain apps to disabled the submit button once the form has been submitted to prevent the user from accidentally/deliberately clicking on it twice. There are two ways to accomplish this, and only one will work in IE. Can you guess which one?

$("form :submit").click(function(){
	$(this).attr("disabled", "disabled").val("Please wait...");
});

$("form").submit(function(){
	$(":submit", this).attr("disabled","disabled").val("Please wait....");
});

See this example in action

In the first example, the submit button will be disabled, its value will be changed, but the form will not submit. Adding a return true; statement will not fix the issue. In the second example, all the behaviors you would expect work in Firefox and IE.

I did some investigating and could not come up with an answer. With the first example you could call a .submit() directly on the form, but this should not be necessary. So, if you want to manipulate the submit button once the form has been submitted, intercept the submit event on the form instead of intercepting the click on the button itself.

Tags: ie, jQuery

This entry was posted on Friday, June 19th, 2009 at 1:53 PM and is filed under jQuery. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

« Previous Post
CFIMAGE resize after CFFILE upload

Next Post »
Changes to TabBasket.com

http://charlie.griefer.com/ Charlie Griefer

This sounds like behavior I’d expect.

In “Plain ol’ JS”, I’ve always thought it was preferable to call a validate method on a form’s submit event rather than a submit button’s click event. I think one of the reasons is that there’s the click event of the button, and then a distinct separate event whereby the submit button submits the form.

That seems to be supported by the results of your first example.

I would have gone with example #2, but would have given the submit an ID and called it that way. Until reading this, didn’t realize you could reference a form’s submit element via ‘:submit’. Very cool.

What’s the 2nd attribute (the ‘this’) in that selector? I assume it restricts the selector to the submit button for the form element that triggered the event, but googling for confirmation has yet to provide worthwhile.
http://charlie.griefer.com Charlie Griefer

This sounds like behavior I’d expect.

In “Plain ol’ JS”, I’ve always thought it was preferable to call a validate method on a form’s submit event rather than a submit button’s click event. I think one of the reasons is that there’s the click event of the button, and then a distinct separate event whereby the submit button submits the form.

That seems to be supported by the results of your first example.

I would have gone with example #2, but would have given the submit an ID and called it that way. Until reading this, didn’t realize you could reference a form’s submit element via ‘:submit’. Very cool.

What’s the 2nd attribute (the ‘this’) in that selector? I assume it restricts the selector to the submit button for the form element that triggered the event, but googling for confirmation has yet to provide worthwhile.
http://charlie.griefer.com/ Charlie Griefer

Oh and weird… this is an old entry. Just came thru the aggregator (again?) today
http://charlie.griefer.com Charlie Griefer

Oh and weird… this is an old entry. Just came thru the aggregator (again?) today
Anonymous

@Charlie, correct, the “this” in the 2nd example gives the selector a context. In this case it’s the form.

I agree, it’s preferable to bind to the form’s submit event rather than the submit button’s click event. Pressing enter to submit the form likely won’t fire the click event

I pinged CFbloggers because a new post of mine never went through the aggregator, which for some reason caused ALL my posts to show up again! whoops.
http://www.erichynds.com Eric Hynds

@Charlie, correct, the “this” in the 2nd example gives the selector a context. In this case it’s the form.

I agree, it’s preferable to bind to the form’s submit event rather than the submit button’s click event. Pressing enter to submit the form likely won’t fire the click event

I pinged CFbloggers because a new post of mine never went through the aggregator, which for some reason caused ALL my posts to show up again! whoops.
http://pulse.yahoo.com/_7BXMX2GWP5IDPRM2CZESY7OYUU diego l

thx for the example