Skip to main content

Bug Tracker

Side navigation

#2114 closed bug (wontfix)

Opened January 04, 2008 11:33AM UTC

Closed February 17, 2008 06:13PM UTC

Last modified October 23, 2013 01:25PM UTC

$(form.elements) fails in IE, selects only the form

Reported by: joern Owned by:
Priority: major Milestone: 1.2.2
Component: core Version: 1.2.1
Keywords: Cc:
Blocked by: Blocking:

Though $([]).add(form.elements) works fine.

Attachments (1)
Change History (14)

Changed January 04, 2008 11:33AM UTC by joern comment:1

Testcase: [4352]

Changed January 04, 2008 11:53AM UTC by joern comment:2

Most likely caused by this optimization in init:

// Handle $(DOMElement)
if ( selector.nodeType ) {
	this[0] = selector;
	this.length = 1;
	return this;

Can't figure out how to fix it.

Changed January 12, 2008 10:38PM UTC by scott.gonzal comment:3

I added a patch which fixes the problem in IE, but this should probably be heavily tested with other selectors to make sure there are no unexpected side effects.

Changed January 14, 2008 09:33AM UTC by joern comment:4

resolution: → fixed
status: newclosed

Fixed in [4436]. Thanks Scott for the patch.

Changed January 14, 2008 09:45AM UTC by joern comment:5

resolution: fixed
status: closedreopened

Reverted 4436, didn't work.

Changed January 15, 2008 03:20AM UTC by scott.gonzal comment:6

I've added a new patch. This time I ran the test suite :-)

The idea is just to not use the optimization on forms (since that's what form.elements looks like in IE). I think the gained functionality outweighs the minor performance hit for $(document.forms![0]). This can also be tweaked to only prevent the optimization in IE.

Changed January 15, 2008 03:11PM UTC by scott.gonzal comment:7

The new patch doesn't work either (well, it works in so far as the constructor now behaves the same as the add method). Trying to create this patch, I found a related bug that exists in all browsers:

$([]).add(form) behaves the same as $([]).add(form.elements).

Changed January 18, 2008 03:49AM UTC by davidserduke comment:8

The problem appears to be that IE actually sticks the elements as array-like RIGHT IN THE FORM element. Then uses form.elements to link back to itself so

form.elements === form

Thus I'm not sure how to fix this since I can't see any way to tell which one the programmer passed in.

Changed February 17, 2008 06:13PM UTC by brandon comment:9

resolution: → wontfix
status: reopenedclosed

We've been able to fix this in the past ... with a very hacky mess which is probably why the fix isn't there anymore. As David mentioned form.elements === form in IE and there isn't a solid way to tell the difference.

A couple of workarounds:

$( $.makeArray(form.elements) );

Changed August 15, 2011 03:14PM UTC by anonymous comment:10

Hi all,

$([]).add(form.elements) won't work in IE8, it just creates an jQuery Object with a length of 1 referring to form.elements.

That means, jQuery validate 1.6 with jQuery 1.6 may be broken in IE8 (always returns valid=true).

Changed September 20, 2011 08:40AM UTC by comment:11

I had an issue where jquery.validate was failing in IE6, caused by the above error. I fixed this by updating line 446 and changed:




Changed September 18, 2012 03:25PM UTC by andros comment:12

I managed to fix the issue by constructing myself the array used in the add() method:

var list = new Array();

for(var k=0;k<this.currentForm.elements.length;k++){

listeElements[k] = this.currentForm.elements[k];



Seems like the issue only appears in the add() method (currentForm.elements returns the form object), but it works fine when listing all elements in a loop.

Changed September 18, 2012 04:00PM UTC by rwaldron comment:13


Changed October 23, 2013 01:25PM UTC by anonymous comment:14

jquery.validate plagin uses this (even the latest 1.11). this way with additional array was the only way to make validation plagin works properly in IE10. thank you andros!