Weird behaviour of iframe `name` attribute set by jQuery in IE

a bug in IE (surely not!?!)

Hard to believe, I know, but there we are.

Historically(*), setting the name attribute has many problems in IE. It tends to only partially hold. For example on form field names, it doesn’t affect the form.elements[name] lookup like it should. This appears to be another case where setting the name property is unreliable.

Whilst jQuery attempts to work around browser bugs like this, it doesn’t catch everything, and there is no known way to solve it fully.

(*: in IE up to 7. If you run IE8 in native documentMode by using a standards mode doctype and if necessary an X-UA-Compatible header/meta, both these errors don’t crop up.)

The submitName appearing in the dev tools is an interesting glimpse behind the scenes of an IE bug, since it doesn’t appear in the publically-visible DOM at all. It does the same thing if you look at an <input> element or <form> whose name attribute has been written after creation, too.

So what appears to be happening is that IE-up-to-7 redirects all use of attributes called name to an otherwise-invisible property, internally called submitName, that for form fields changes the data the field will generate as part of a form submission, but which doesn’t change the real name attribute used for HTMLCollection indexing, radio-grouping, getElementsByName, or, in the case of [i]frames, targeting.

Leave a Comment