Bug 22577 - Add a test to verify accessing INPUT elements with duplicate names
: Add a test to verify accessing INPUT elements with duplicate names
Status: RESOLVED FIXED
: WebKit
HTML DOM
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-12-01 16:10 PST by
Modified: 2008-12-17 13:41 PST (History)


Attachments
New test + result (2.74 KB, patch)
2008-12-01 16:15 PST, Pam Greene (IRC:pamg)
no flags Review Patch | Details | Formatted Diff | Diff
Patch addressing Eric's comments in IRC (3.37 KB, patch)
2008-12-03 13:38 PST, Pam Greene (IRC:pamg)
darin: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-12-01 16:10:56 PST
Make sure checkboxes and radio buttons with identical names are mapped to a collection when accessed via document.form.name.
------- Comment #1 From 2008-12-01 16:15:56 PST -------
Created an attachment (id=25642) [details]
New test + result
------- Comment #2 From 2008-12-03 13:38:28 PST -------
Created an attachment (id=25722) [details]
Patch addressing Eric's comments in IRC

You can get to the list of elements with the same name either through document.(form).(name) or document.getElementsByName(name).  Oddly, not only is there no consistency in what object different browsers map the two access methods to, but most don't even map the two to the same thing.

[browser: document.form.name and document.getElementsByName()]

Safari 3.2.1 and trunk: Collection and NodeList
Firefox 3.0.4: NodeList and HTMLCollection
Chrome 0.4.154.29: NodeList and NodeList
IE 6: object and object

Hard even to call that a bug, since nobody can be relying on it for anything much.

So the test still checks only that whatever object they each map to has a length property. I've also clarified the description and added getElementsByName checks.
------- Comment #3 From 2008-12-04 09:15:01 PST -------
(From update of attachment 25722 [details])
r=me

For future reference, even if something is not standardized it's good to have the regression test check it. These aren't portable tests for other browsers, but rather regression tests for WebKit.

It's sensible to structure the test so that those things are separate, but we want to exercise as much code as possible so we should test everything, even things that are not consistent.
------- Comment #4 From 2008-12-17 11:23:27 PST -------
Will land.
------- Comment #5 From 2008-12-17 11:56:40 PST -------
Sorry for leaving this on the queue. I was hoping to write a more thorough test, but I've since gotten mired in other things and won't be getting back to this for a bit.  So you're welcome to land it; I'll improve it later.
------- Comment #6 From 2008-12-17 13:41:43 PST -------
LayoutTests/ChangeLog: locally modified
LayoutTests/fast/dom/null-document-xmlhttprequest-open.html: locally modified
LayoutTests/fast/dom/xmlhttprequest-invalid-values.html: locally modified
    M    LayoutTests/ChangeLog
    A    LayoutTests/fast/dom/HTMLInputElement/duplicate-element-names-expected.txt
    A    LayoutTests/fast/dom/HTMLInputElement/duplicate-element-names.html
Committed r39364
    M    LayoutTests/ChangeLog
    A    LayoutTests/fast/dom/HTMLInputElement/duplicate-element-names-expected.txt
    A    LayoutTests/fast/dom/HTMLInputElement/duplicate-element-names.html
r39364 = 182b729ccd692478c593c94b7895ca69cde1118d (trunk)