322488 - named control may override the attribute or method of HTMLFormElement

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[HE Shi-Jun]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

DOM level 0 support access form controls via such script: 
var f = document.forms[0];
var control1 = f['controlNameOrId'];
var control2 = f.controlNameOrId;

Though DOM HTML spec provide HTMLFormElement.elements to replace this approach, but MSIE and Firefox still remain this problematic feature.

The issue here is named control may override the attribute or method of HTMLFormElement. For example, if there is <input name="action" /> in the form, then document.forms[0].action will return that HTMLInputElement. And there is a bizarre behavior in firefox that assign still works :)

document.forms[0].action = 'http://url'
alert(document.forms[0].action == 'http://url')
document.forms[0].submit()

the 1st line is ok in Firefox(but failed in MSIE), but I find no way to retrieve it back. the 2nd line will alert false, but u still submit to http://url (if there is no control named 'submit' :)

Such behavior is undocumented (maybe i missed...), and will confuse developers if they unfortunately meet some controls named 'method', 'length', 'id', 'item'(IE only), 'target', 'elements'...

To make the script works, especially when you write a reused component or script library, there should be no such uncontrolled name conflict. But in most case the web page is written by designer who has no concern about script, so it's hard to avoid such case. And, even a script master won't remember all attribute/method of HTMLFormElement.

As a conclusion, form['controlName'] approach should be removed or limited(ie. won't override the attribute/method of HTMLFormElement).




Reproducible: Always

Comment 1

[Juriy "kangax" Zaytsev]

I can certainly confirm this behavior. Also, see "Unsafe Names" [1] article which describes everything quite thoroughly.

It would be nice to see some progress regarding this "annoyance" in browsers (and Firefox in particular).

[1] http://jibbering.com/faq/names/

Comment 2

[Juriy "kangax" Zaytsev]

Couldn't find dupes. Marking as NEW.

Comment 3

[Juriy "kangax" Zaytsev]

While it certainly makes sense to prevent same-named form controls overriding members of one of the HTMLFormElement interfaces, I'm afraid this change could break some of the existing applications that might accidentally (or deliberately) rely on it.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Per <http://www.whatwg.org/html/#the-form-element>, HTMLFormElement has [OverrideBuiltins], so this is actually the correct behaviour.