Bug 120279 – Elements in a node list of the form element's name getter should not be added to the past names map

• Component: Forms
• Status: RESOLVED FIXED

[Ryosuke Niwa]

Created attachment 209610 [details]
Test case

The current HTML5 specification
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
says:

1. Let candidates be a live RadioNodeList object containing all the listed elements whose form owner is the form element that have either an id attribute or a name attribute equal to name, with the exception of input elements whose type attribute is in the Image Button state, in tree order.

2. If candidates is empty, let candidates be a live RadioNodeList object containing all the img elements that are descendants of the form element and that have either an id attribute or a name attribute equal to name, in tree order.

3. If candidates is empty, name is the name of one of the entries in the form element's past names map: return the object associated with name in that map.

4. If candidates contains more than one node, return candidates and abort these steps.

5. Otherwise, candidates contains exactly one node. Add a mapping from name to the node in candidates in the form element's past names map, replacing the previous entry with the same name, if any.

6. Return the node in candidates.

Steps 4-5 indicate that we should NOT be adding anything to the past names map when there are multiple elements found in steps 1-3.
However, this is not what WebKit or Gekko does. At least both of these engines DO add the first element of those found in steps 1-3 to the past names map even when there are multiple elements at step 4.

We need to figure out whether this is a bug in the specification, or we need to change our behavior due to some backward compatibility issues (maybe this is the Trident behavior?).

[Ryosuke Niwa]

Confirmed. The specification matches IE10's behavior.

[Kent Tamura]

Oh, I didn't know this behavior was standardized.
So, Blink r156140 [1] was wrong.  My test for IE10/IE11 might have been incorrect.

[1] http://src.chromium.org/viewvc/blink?view=revision&revision=156140

[Ryosuke Niwa]

(In reply to comment #2)
> Oh, I didn't know this behavior was standardized.
> So, Blink r156140 [1] was wrong.  My test for IE10/IE11 might have been incorrect.
> 
> [1] http://src.chromium.org/viewvc/blink?view=revision&revision=156140

Indeed.  It'll be really nice to be able to remove this feature but I don't think we can :(  We can at least limit the scope. See my latest post on WHATWG:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040586.html

[Ryosuke Niwa]

Created attachment 209683 [details]
Fixes the bug

[Ryosuke Niwa]

Committed r154662: <http://trac.webkit.org/changeset/154662>