Bug 85937 – [Chromium][Forms] HTMLOptionsCollection doesn't have indexed properties on property enumeration

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

ConsoleMessage._printArray takes elements of array object of inspector's internal representation from numeric property name. However, HTMLOptionsCollection object don't have such properties.

Even though, getting a element works in scripts in original HTML and JavaScript console.

Below is sample steps:

1. Visit data:text/html,<form><select id="s"><option value="1">one</option><option value="2">two</option></select></form>
2. Invoke JavaScript Console
3. Enter "keys(documents.forms)"
  ["0", "length"]
4. Enter "keys(s.options)"
  ["selectedIndex", "length"]
5. Enter: "s.options
  []

Note: Safari's JavaScript console works fine.

Object.keys(select.options) should return an array of property keys containing numeric index value, e.g. ["0", "1", "selectedIndex", "length"].

Here is test result of browsers with simple test http://jsfiddle.net/MbtFP/5/
* FF12 OK
* Chrome18 NOT -- no "0" and "1"
* IE9 OK
* Opera11 OK

Created attachment 140863 [details]
Patch

This bug blocks http://crbug.com/121890 - DOM Select Object always returns empty list for options attribute

[Kentaro Hara]

Comment on attachment 140863 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140863&action=review

What is happening for other interfaces that have indexed properties? I mean, should this change be for HTMLOptionsCollection only?

> Source/WebCore/ChangeLog:10
> +

Please describe other browsers' behavior in ChangeLog, to justify your change.

Created attachment 140864 [details]
Patch

[WebKit Review Bot]

Comment on attachment 140864 [details]
Patch

Attachment 140864 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12662002

New failing tests:
inspector/console/console-format-collections.html

[WebKit Review Bot]

Created attachment 140872 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

Created attachment 140875 [details]
Patch 3

[Kentaro Hara]

(In reply to comment #4)
> What is happening for other interfaces that have indexed properties? I mean, should this change be for HTMLOptionsCollection only?

Would you clarify the above point? I am not sure if we should fix HTMLOptionsCollection specific code or more general IndexedProperty code.(In reply to comment #0)
> ConsoleMessage._printArray takes elements of array object of inspector's internal representation from numeric property name. However, HTMLOptionsCollection object don't have such properties.
> 
> Even though, getting a element works in scripts in original HTML and JavaScript console.
> 
> Below is sample steps:
> 
> 1. Visit data:text/html,<form><select id="s"><option value="1">one</option><option value="2">two</option></select></form>
> 2. Invoke JavaScript Console
> 3. Enter "keys(documents.forms)"
>   ["0", "length"]
> 4. Enter "keys(s.options)"
>   ["selectedIndex", "length"]
> 5. Enter: "s.options
>   []
> 
> Note: Safari's JavaScript console works fine.

(In reply to comment #9)
> (In reply to comment #4)
> > What is happening for other interfaces that have indexed properties? I mean, should this change be for HTMLOptionsCollection only?
> 
> Would you clarify the above point? I am not sure if we should fix HTMLOptionsCollection specific code or more general IndexedProperty code.(In reply to comment #0)

This change should affect HTMLOptionCollection only. 

Enumerator should be attached for indexed properties. In IDL which is specified by IndexedGetter(HTMLCollection, HTMLSelect), NumericIndexer({Float,Int,UInt}{16,32,64,8}Array), or CustomGetOwnPropertySlot (no use case, HTMLAppletElement, HTMLEmbedElement, HTMLObjectElement have JSCustomGetOwnPropertySlotAndDescriptor). 

Code generator doesn't generate code for NumericIndexer, CustomGetOwnPropertySlot is handlbed by (%indexerSpecialCases hash map, we should add this attribute to these interfaces and remove %indexerSpecialCases).

For interfaces which have IndexedGetter, GenerateImplementationIndexer generates code of calling setCollectionXXX<T> which setting enumerator if interfaces inherited from Node or no CustomSetter, e.g. HTMLSelectElement interface has IndexedGetter and CustomSetter attribute, HTMLCollection has IndexedGetter attribute but no CustomSetter.

[Kentaro Hara]

Comment on attachment 140875 [details]
Patch 3

View in context: https://bugs.webkit.org/attachment.cgi?id=140875&action=review

The patch looks good to me.

> LayoutTests/fast/forms/select/options-indexed-properties.html:11
> +</select>

Nit: Remove this.

> LayoutTests/fast/forms/select/options-indexed-properties.html:23
> +for (var propertyKey in options) {
> +    properties[propertyKey] = options[propertyKey];
> +}
> +shouldBe('properties[0].value', '"a"');
> +shouldBe('properties[1].value', '"b"');

You might want to write this as follows:

shouldBeEqualToString('options[0].value', "a");
shouldBeEqualToString('options[1].value', "b");

> LayoutTests/fast/forms/select/options-indexed-properties.html:29
> +

Nit: Remove the redundant new line.

Created attachment 140893 [details]
Patch 4

[WebKit Review Bot]

Comment on attachment 140893 [details]
Patch 4

Clearing flags on attachment: 140893

Committed r116513: <http://trac.webkit.org/changeset/116513>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.