Bug Tracker

Opened 15 years ago

Closed 15 years ago

Last modified 9 years ago

#2114 closed bug (wontfix)

$(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)

formelements.patch (946 bytes) - added by scottgonzalez 15 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 15 years ago by joern

Testcase: [4352]

comment:2 Changed 15 years ago by joern

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.

comment:3 Changed 15 years ago by scott.gonzal

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.

comment:4 Changed 15 years ago by joern

Resolution: fixed
Status: newclosed

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

comment:5 Changed 15 years ago by joern

Resolution: fixed
Status: closedreopened

Reverted 4436, didn't work.

Changed 15 years ago by scottgonzalez

Attachment: formelements.patch added

comment:6 Changed 15 years ago by scott.gonzal

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.

comment:7 Changed 15 years ago by scott.gonzal

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).

comment:8 Changed 15 years ago by davidserduke

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.

comment:9 Changed 15 years ago by brandon

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) );

comment:10 Changed 11 years ago by anonymous

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).

comment:11 Changed 11 years ago by [email protected]

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:




comment:12 Changed 10 years ago by andros

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.

comment:13 Changed 10 years ago by Rick Waldron


comment:14 in reply to:  12 Changed 9 years ago by anonymous

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!

Note: See TracTickets for help on using tickets.