Bug 150957 – HTMLCollection.namedItem implementations should conform to spec

• Status: NEW
• Component: DOM

[Keith Rollin]

Our various 'namedItem' implementations do not match the DOM/HTML specs.

The DOM spec for HTMLCollection.namedItem (https://dom.spec.whatwg.org/#dom-htmlcollection-nameditem) says:

> The namedItem(key) method must run these steps:
> 
> * If key is the empty string, return null.
> * Return the first element in the collection for which at least one of the
>   following is true:
>   * it has an ID which is key;
>   * it has a name attribute whose value is key;
> * or null if there is no such element.

HTMLFormControlsCollection and HTMLOptionsCollection both derive from HTMLCollection. The HTML spec for HTMLFormControlsCollection (https://html.spec.whatwg.org/#the-htmlformcontrolscollection-interface) says:

> The namedItem(name) method must act according to the following algorithm:
> 
> * If name is the empty string, return null and stop the algorithm.
> * If, at the time the method is called, there is exactly one node in the
>   collection that has either an id attribute or a name attribute equal to
>   name, then return that node and stop the algorithm.
> * Otherwise, if there are no nodes in the collection that have either an id
>   attribute or a name attribute equal to name, then return null and stop the
>   algorithm.
> * Otherwise, create a new RadioNodeList object representing a live view of
>   the HTMLFormControlsCollection object, further filtered so that the only
>   nodes in the RadioNodeList object are those that have either an id
>   attribute or a name attribute equal to name. The nodes in the RadioNodeList
>   object must be sorted in tree order.
> * Return that RadioNodeList object.

The HTML spec for HTMLOptionsCollection (https://html.spec.whatwg.org/#the-htmloptionscollection-interface) does not state a specialization for namedItem, and so inherits the base behavior.

HTMLAllCollection (used for the document.all attribute) does not derive from HTMLCollection, but it internally shares the same base implementation, and so is included in this discussion. The HTML spec for HTMLAllCollection (https://html.spec.whatwg.org/#the-htmlallcollection-interface) says:

> The item(name) and namedItem(name) methods must act according to the following
> algorithm:
> 
> * If name is the empty string, return null and stop the algorithm.
> * Let collection be an HTMLCollection object rooted at the same Document as
>   the HTMLAllCollection object on which the method was invoked, whose filter
>   matches only elements that are either:
>   * "all"-named elements with a name attribute equal to name, or,
>   * elements with an ID equal to name.
> * If, at the time the method is called, there is exactly one node in
>   collection, then return that node and stop the algorithm.
> * Otherwise, if, at the time the method is called, collection is empty,
>   return null and stop the algorithm.
> * Otherwise, return collection.

In the above '"all"-named elements' are: a, applet, button, embed, form, frame, frameset, iframe, img, input, map, meta, object, select, and textarea.

None of our implementations match the specs. Non-conformance includes, but is not limited to:

* HTMLCollection.namedItem first iterates over elements with id attributes and then attributes with name attributes when looking for a match, rather than iterating over all elements that have either an id or name attribute (or both) looking to see if either matches.
* HTMLFormControlsCollection does not return a RadioNodeList in the case of multiple matches. (WebKit's HTMLCollection class *does* have a namedItems method that Javascript uses as part of HTMLFormControlsCollection.namedItem, so this discrepancy in namedItem is largely moot.)
* HTMLFormControlsCollection does not iterate in tree order, so if there were multiple items with matching ids/names, the caller might not get the expected one.
* HTMLFormControlsCollection is a collection of "listed elements" (https://html.spec.whatwg.org/#category-listed), which are "button, fields, input, keygen, object, output, select, and textarea". However, our implementation seems to include images as well.
* HTMLFormControlsCollection, HTMLOptionsCollection, and HTMLAllCollection -- as with HTMLCollection -- also search for matching ids first, then for matching names. HTMLOptionsCollection has both "fast" and "slow" paths, both of which share this behavior.
* HTMLAllCollection doesn't seem to restrict its searches to the given set of elements.
* HTMLAllCollection doesn't seem to return an HTMLCollection when there are multiple results. From a comment in JSHTMLAllCollectionCustom.cpp:namedItems: "FIXME: HTML5 specification says this should be a HTMLCollection".

These issues were turned up when performing some testing on HTMLOptionsCollection.namedItem. This testing indicated that Firefox conforms to the spec (at least as far as HTMLOptionsCollection.namedItem goes), but Safari and Chrome do not.

[Radar WebKit Bug Importer]

<rdar://problem/23420620>

[Ahmad Saleem]

By searching 'namedItem', we only fail following tests here:

https://wpt.fyi/results/html/dom/documents/dom-tree-accessors/nameditem-names.html?label=master&label=experimental&aligned=&q=namedItem