FormTagHelper#submit_tag with :disable_with option doesn't submit the button's value when clicked
Reported by Jose Fernandez | July 16th, 2008 @ 10:49 AM | in 2.x
When the :disable_with option is used in the FormTagHelper#submit_tag, the button's value isn't passed along in the parameters, { :commit => 'Foobar' }.
This occurs because when :disabled_with is used, we overwrite the onclick event and manually submit the form executing 'this.form.submit()'. Thus, the submit button acts as if it was never clicked. Also, disabled input fields do not get submitted.
This is a problem when you have forms with more than one submit_tag's, and your update/create logic is depending on the 'commit' value to react accordingly.
What the patch does is add some js at the beggining of the onclick event, so that it clones the submit_tag into a hidden input element with the original values. This way way when the form is finally submitted, it still passes along the submit button value.
The FormTagHelper submit_tag tests have also been refactored to support this new feature.
Comments and changes to this ticket
-
Jose Fernandez July 16th, 2008 @ 11:09 AM
Clarification: The submit_tag original value is the one that gets submitted, not the disable_with one.
-
Jonathan Dance July 16th, 2008 @ 03:57 PM
If this is a bug, the patch would be more awesome if it had a test that would fail without this patch, e.g. the value of the submit button should be passed when using :disable_with.
-
Jose Fernandez July 16th, 2008 @ 04:58 PM
- → Tag changed from “actionpack helper patch tested” to “actionpack bug helper patch tested”
The problem with that is how to simulate a click on the submit_tag and a mocked form submission (in order to check that the hidden input fields gets successfully created and passed long the request).
I think as long as the modified submit_tag tests do a dom check that includes the extra js, its all good.
-
Jonathan Dance July 16th, 2008 @ 05:02 PM
Hm, I guess it would require Selenium (or something similar). Oh well, it was a good thought.
+1
-
Pratik July 16th, 2008 @ 07:27 PM
- → Title changed from “[PATCH] FormTagHelper#submit_tag with :disable_with option doesn't submit the button's value when clicked” to “FormTagHelper#submit_tag with :disable_with option doesn't submit the button's value when clicked”
-
Lawrence Pit July 20th, 2008 @ 08:51 PM
I think you need to test whether the hidden field already exists or not. This is because the form can have a custom onsubmit handler (doing some ajax stuff for example). When that fails, the submit button is enabled again. When you press submit again, the current patch will again add a hidden field.
-
Jose Fernandez July 20th, 2008 @ 10:10 PM
I was actually thinking about that issue recently, will update patch tomorrow
-
Jose Fernandez July 21st, 2008 @ 12:02 PM
- no changes were found...
-
Jose Fernandez July 21st, 2008 @ 12:02 PM
Updated the patch with a a check to see if the reference to the dynamically created (hiddenCommit) element exists in the window object before creating and appending it again.
Tests have also been updated, all passed too.
-
John Dell August 18th, 2008 @ 04:32 PM
+1
We were bitten by this bug. Would love to see this fixed in Rails 2.1.1
-
Pratik August 18th, 2008 @ 04:45 PM
- → Assigned user changed from “” to “Pratik”
-
Ryan Bates August 18th, 2008 @ 06:26 PM
+1, I've run into this problem before too.
But does this patch handle the case where a different button is pressed after the original onsubmit failed? Maybe add an "else" condition if the hidden field exists and override the value there.
-
-
Jose Fernandez August 19th, 2008 @ 05:21 PM
Here's the updated patch. It will check the window DOM object for the hiddenCommit element and update the value if it already exists, or create it otherwise.
I also stopped using the array of strings + joining with ';' way of writing the javascript since it was causing problems with the if/else js statements.
Tests were also updated, both passed.
-
Jose Fernandez August 19th, 2008 @ 05:25 PM
Oh yeah, and I also switched the += operator with << at line 363.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
The latest development for the 1.2.x and 2.0.x releases are on the 1-2-stable and 2-0-stable branches.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
