Side navigation
#1414 closed bug (wontfix)
Opened July 21, 2007 02:40AM UTC
Closed January 06, 2011 11:45PM UTC
Last modified April 04, 2013 12:15AM UTC
.submit() can fail if something has id="submit"
Reported by: | john | Owned by: | john |
---|---|---|---|
Priority: | undecided | Milestone: | 1.5 |
Component: | event | Version: | 1.4.4rc |
Keywords: | expando attr | Cc: | |
Blocked by: | Blocking: |
Description
If an element with an ID of submit exists in a form, .submit() can fail. It's important that this function (in particular) work correctly.
Attachments (2)
Change History (26)
Changed November 20, 2007 04:33AM UTC by comment:1
need: | Patch → Test Case |
---|
Changed November 28, 2007 06:50PM UTC by comment:2
milestone: | 1.1.4 → 1.2.2 |
---|---|
need: | Test Case → Patch |
summary: | .submit() can fail in IE → .submit() can fail if something has id="submit" |
This doesn't appears to be limited to IE. I was able to reproduce the bug in IE, FF, Opera, and Safari. Basically it looks like the jQuery.event.trigger() function checks to see if elem[type] is a function where elem is the <form> and type == "submit".
Unfortunately, when there is an element with an id of "submit" it returns that element instead of the function. It basically shadows the function. At this point, I'm not even sure how to get TO the function.
One thing I did notice is:
when f.submit is a function
f.hasOwnProperty("submit") == false
when f.submit is an element
f.hasOwnProperty("submit") == true
So we could, in theory, do a special case test to see if it is the "wrong" submit and do something else in that case. Unfortunately, as I already mentioned, the submit function is hidden. Perhaps this would work?
$("<form/>").get(0).submit.call(elem);
Not very pretty though. And further testing shows it fails in IE because submit.call is undefined.
Any other thoughts on a possible fix?
Changed December 06, 2007 09:04PM UTC by comment:3
These lines are used to reach the action and method attributes of a form in IE:
else if ( value == undefined && jQuery.browser.msie && jQuery.nodeName( elem, "form" ) && (name == "action" || name == "method") ) return elem.getAttributeNode( name ).nodeValue;
That may work for submit, too.
Changed December 06, 2007 09:14PM UTC by comment:4
Of course that won't work in any other browser then IE. And even there is doesn't seem to work. Forget it then...
Changed May 16, 2008 04:00AM UTC by comment:5
milestone: | 1.2.2 → 1.2.4 |
---|
Also, submit is not an attribute, so that function won't work.
Changed August 18, 2008 05:02AM UTC by comment:6
I'd say this is a problem with the HTML spec, not jQuery. What is happening is exactly equivalent to this:
<form action="" method="get"> <input name="submit" id="submit" type="text /> <a href="#" onclick="this.parentNode.submit(); return false;"></a> </form>
With the way forms work for accessing descendant inputs, the child element "submit" is essentially hiding the "submit" method. This is a problem with any attempt to submit a form with JavaScript, not with our implementation. I think we should just leave this one to education: thou shalt not name/id a form element "submit" or "reset" because they hide methods.
In terms of a workaround, we could try adding an <input type="text" /> set focus, and insert a return...
Changed August 19, 2008 12:17PM UTC by comment:7
resolution: | → duplicate |
---|---|
status: | new → closed |
This is an old ticket (1.1.3). The compromised is now wrapped with a try/catch so this shouldn't cause any exception.
Reopen if you still experience a problem.
Changed August 19, 2008 12:33PM UTC by comment:8
milestone: | 1.2.4 → 1.3 |
---|---|
resolution: | duplicate |
status: | closed → reopened |
version: | 1.1.3 → 1.2.6 |
Well, it doesn't throw an exception, correct - but it needs to actually work. Right now we just kind of fall on our side if no event is provided to us. One option is to create a temporary form and utilize its .submit property to force a submission (haven't tested this, may not work).
Changed August 20, 2008 04:15PM UTC by comment:9
Then if we must, I think the easiest way to trigger submit will be to do something like this:
$('<input type="submit" style="display: none;"/>').appendTo('form').trigger('click');
I don't know how that would affect other event handlers being fired (I know that catching the submit event isn't always easy), but it seems to work in the simple test case I created.
Changed August 20, 2008 07:19PM UTC by comment:10
I proposed a solution to Ariel over IM - to add some code to our event triggering code that looks something like this:
document.createElement( elem.nodeName )[ method ].call( elem );
I haven't tested it yet to see if it actually works - but it's worth a shot.
Changed November 09, 2010 03:22AM UTC by comment:11
#6264 is a duplicate of this ticket.
Changed November 11, 2010 10:53PM UTC by comment:12
keywords: | → expando attr |
---|---|
milestone: | 1.3 → 1.5 |
priority: | major → blocker |
status: | reopened → open |
version: | 1.2.6 → 1.4.4rc |
This is one of those things that should probably get resolved along with the attr rewrite which also targets addressing the DOM expando crap.
Changed December 03, 2010 09:01PM UTC by comment:13
#7699 is a duplicate of this ticket.
Changed December 16, 2010 09:18PM UTC by comment:14
Solution to this would be to call the method from the prototype chain.
HTMLFormElement.prototype.submit.call(elem);
Changed December 17, 2010 12:41AM UTC by comment:15
i just ran into this and spent 3 hours trying to figure out why submit() wasn't working on my form. turned out the form had an input element with name="submit". when i renamed it to something else, submit() worked again. would be great to see this fixed soon.
Changed December 20, 2010 08:18PM UTC by comment:16
@anonymous-14 it turns out that that solution is not IE<7 compatible. Check out Matt's solution here: http://stackoverflow.com/q/4465028/172322 ; It seems to work fairly well, and doesn't seem to present any cross-browser issues.
Changed January 06, 2011 11:45PM UTC by comment:17
priority: | blocker → undecided |
---|---|
resolution: | → wontfix |
status: | open → closed |
After a lot of research and attempts to patch this over the last 2 days and ultimately over the last three years, I think its safe to say its a "needsdocs" situation.
What have we learned? DO NOT USE "submit" or "reset" as input name attribute values.
Epic work, documented here: https://github.com/gnarf37/jquery/commits/bug_1414
Changed January 06, 2011 11:56PM UTC by comment:18
_comment0: | https://gist.github.com/877c36fa541d01afd022 → 1294358223248250 |
---|
https://gist.github.com/877c36fa541d01afd022
Adapted from https://gist.github.com/877c36fa541d01afd022
This also doesn't work.
Changed January 07, 2011 12:01AM UTC by comment:19
Shows the patch at https://github.com/gnarf37/jquery/commits/bug_1414 in action...
http://gyazo.com/2c1e5048c2713d7e4f00411ffdaa8cb9.png
And its downfall...
Changed January 07, 2011 12:03AM UTC by comment:20
Replying to [comment:17 rwaldron]:
After a lot of research and attempts to patch this over the last 2 days and ultimately over the last three years, I think its safe to say its a "needsdocs" situation.
Already doced on
.submit()
Forms and their child elements should not use input names or ids that conflict with properties of a form, such as submit, length, or method. Name conflicts can cause confusing failures. For a complete list of rules and to check your markup for these problems, see DOMLint.
Changed February 20, 2011 09:44PM UTC by comment:21
#8330 is a duplicate of this ticket.
Changed March 16, 2011 06:58PM UTC by comment:22
#8544 is a duplicate of this ticket.
Changed November 20, 2011 08:08PM UTC by comment:23
#10839 is a duplicate of this ticket.
Changed November 28, 2011 07:30PM UTC by comment:24
#10909 is a duplicate of this ticket.
Changed April 04, 2013 12:04AM UTC by comment:25
This is a problem that can cause hours of headaches for developers. Understand that it seems to tough to fix. But as noted here, this is a "needsdocs" situation and the documentation for .submit() should definitely be updated accordingly at http://api.jquery.com/submit/
Changed April 04, 2013 12:15AM UTC by comment:26
There are dozens of properties that can cause this. It's not just submit. If you want to go through the list here and propose a reasonable set of changes to a series of pages it would be welcome.
http://kangax.github.com/domlint/
The pull request should be submitted to http://github.com/jquery/api.jquery.com/
Can you please submit a test case showing when submit fails?