578632 - HTMLFormElement.elements.namedItem("elem-name") should return a collection for multiple elements with the same name

Status: RESOLVED WORKSFORME

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

Description

[Stanimir Stamenkov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 SeaMonkey/1.1.19 (Spidey; Mnenhy 0.7.6)
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre

Having multiple elements with the same name in a form:

  <input type="checkbox" name="stuff" value="1">
  <input type="checkbox" name="stuff" value="2">
  <input type="checkbox" name="stuff" value="3">

Gecko yields different results for:

HTMLFormElement.elements["stuff"]

and:

HTMLFormElement.elements.namedItem("stuff")

The first one returns a collection of all form elements with the given name, while the second returns just a single element.  The second one adheres to the current DOM Level 2 HTML spec [1], while the first behaves as what's commonly implemented in browsers - latest versions of Opera/Safari/Chrome/IE return a collection using both forms of access and the HTML 5 draft also specifies [2] it should be like that.

[1] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-76728479
[2] http://dev.w3.org/html5/spec/forms.html#dom-form-elements

Reproducible: Always

Comment 1

[Stanimir Stamenkov]

Attachment: Sample test

Comment 2

[Boris Zbarsky [:bzbarsky]]

Doing this in a reasonable way involves "overriding" the namedItem from HTMLCollection on whatever interface form.elements would return.  Do we support doing that sort of thing in xpidl?

Comment 3

[Benjamin Smedberg]

We have at least one case of this already. I don't think you can override in a *derived* interface, but if you have two independent interfaces, xpconnect makes sure that whichever one shows up last in classinfo wins any conflicts.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  We actually do need the derived bit, to make instanceof work right, no?  That's a bit unfortunate...

Comment 5

[Benjamin Smedberg]

No, I don't think you do. You can add an interface without changing instanceof behavior.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The object needs to be both instanceof HTMLCollection and instanceof HTMLFormControlsCollection.  Per the spec, the latter interface inherits from the former...

Comment 7

[Benjamin Smedberg]

Are spec interfaces exposed to script? If so, is there any rule that we cannot have a nsIMozillaHTMLFormControlsCollection which is invisible to script, but has the override version of .namedItem?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Are spec interfaces exposed to script?

Yes.

> is there any rule that we cannot have a nsIMozillaHTMLFormControlsCollection
> which is invisible to script

Hmm...  No, but I'm not sure we have a way of creating interfaces that aren't visible to script.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I guess we've got to, though.  I'll see what I can do here.

Comment 10

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

Attachment: WIP

Still need to test.

Comment 11

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

I never really got around to fixing this; might take it up later.

Comment 12

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

Seems to have been fixed by bug 648801.

Comment 13

[Boris Zbarsky [:bzbarsky]]

nsFormControlList::NamedItem is still just returning one node.  Is that just not being called by the new JS bindings?  It seems bad to have different behavior here for JS vs C++.....

Comment 14

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

Attachment: Cleanup nsIDOMHTMLCollection::NamedItem implementations

I thought you'd say that. How about this?

Comment 15

[Peter Van der Beken [:peterv]]

(In reply to Boris Zbarsky (:bz) from comment #13)
> nsFormControlList::NamedItem is still just returning one node.  Is that just
> not being called by the new JS bindings?  It seems bad to have different
> behavior here for JS vs C++.....

Boris, if you think we should fix that on branch we can move the [getter] to getNamedItem and remove the [forward(getNamedItem)] from namedItem. File a bug if you think we should do that, I'll make a patch.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I don't think we should worry about it for branch.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 588974 [details] [diff] [review]
Cleanup nsIDOMHTMLCollection::NamedItem implementations

nsFormControlList::NamedItem has an extra flush and set of aReturn that can go away.

And you need to rev all the relevant IIDs.

r=me with that.

Comment 18

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

Turns out that mozilla::dom::binding::HTMLCollection_NamedItem calls GetNamedItem, so despite the fact that the code in nsFormControlList::NamedItem, the attached test case passes...

Comment 19

[Stanimir Stamenkov]

WFM with recent Geckos.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Yeah, this got fixed a long while ago, as part of various bindings work.