The default bug view has changed. See this FAQ.

Implement index property on <option> in <datalist>

RESOLVED FIXED in mozilla13



DOM: Core & HTML
5 years ago
5 years ago


(Reporter: Codacoder, Assigned: mounir)


({dev-doc-complete, html5})

dev-doc-complete, html5
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [parity-webkit][parity-opera][parity-ie][mentor=Ms2ger][lang=c++], URL)


(2 attachments)



5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

Created a datalist with simple set of options.  Each option has an id.

Actual results:

opt = opts["id-of-opt"]  
opt.index <-- returns -1
opt = opts[0] 
opt.index <-- returns -1

Expected results:

option.index should work as specified - return index of option in collection.
I can confirm that the index property only returns -1 when the <option>s are in a <datalist> although it works fine when they are instead in a <select>.

"An option element's index is the number of option element that are in the same list of options but that come before it in tree order. If the option element is not in a list of options, then the option element's index is zero." [1]
Blocks: 555840
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Keywords: html5
OS: Windows Vista → All
Product: Firefox → Core
QA Contact: untriaged → general
Hardware: x86 → All
Summary: datalist option has invalid index property → Implement index property on <option> in <datalist>
Whiteboard: parity-webkit
Version: 9 Branch → Trunk


5 years ago
Keywords: testcase-wanted
"list of options" is only defined for select elements, not for datalists, so we should return 0.
Created attachment 597578 [details]
Testcase comparing <select> and <datalist> behaviour

It may be worth proposing a spec change to have "list of options" also defined for <datalist> but currently Opera, & Webkit align with the spec.
Attachment #597578 - Attachment is patch: false
Attachment #597578 - Attachment mime type: text/plain → text/html
Keywords: testcase-wanted
Whiteboard: parity-webkit → [parity-webkit][parity-opera]
IE 10 PP also returns 0 for the index property of an <option> in a <datalist>.
Whiteboard: [parity-webkit][parity-opera] → [parity-webkit] [parity-opera] [parity-ie]
Code is here:

and needs to be updated to match the specification at
Whiteboard: [parity-webkit] [parity-opera] [parity-ie] → [parity-webkit][parity-opera][parity-ie][mentor=Ms2ger]


5 years ago
Whiteboard: [parity-webkit][parity-opera][parity-ie][mentor=Ms2ger] → [parity-webkit][parity-opera][parity-ie][mentor=Ms2ger][lang=c++]

Comment 6

5 years ago
Yep you guys a correct - my bad.  

I just wonder what the whatwg were smoking when they came up with a datalist element (note "list") that contains a "list of options" that somehow does not qualify as a list-of-options as per the spec:

"If the option element is not in a list of options, then the option element's index is zero."

And I'm told by one of them "It's too late to change it, in any case; it's already shipped in browsers."  I'm further told it's only intended for use by the list="" attribute on other controls.  I guess it must be my fault for trying to use a datalist as a, uh, "list" of, you know, "data".

Anyway, yes, zero it should be.
(In reply to Russ from comment #6)

Unhelpful. if you want the spec to be changed, there are numerous ways to submit feedback (see This bug, however, is not one of those ways.

Comment 8

5 years ago
Unhelpful? To whom?  What???  The original report is wrong, agreed.  It's still a bug (as per spec - should return zero, mentioned in my comment, at the top and the bottom).  Rest of my comment was sharing "where I'd been".

So, let's be helpful:

When an option is a member of a list of options that make up the list of options within a datalist element the option is not considered to be a member of a [list of options] as defined by the spec.

Comment 9

5 years ago
What would that change if you had .index returning a value other than 0? Unless there is a real use case, I think we should just comply with the specs: it will be hard to have all browsers to move to something else for no big enough reason.

Comment 10

5 years ago
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #9)
"List" implies "order".  Order implies position.  Position (index of) should be discoverable.  An index of zero is meaningless.  What we have is a bag, or a set, not a list.

Yes, we should comply with the spec.  No one is suggesting otherwise.

Comment 11

5 years ago
Created attachment 597895 [details] [diff] [review]
Patch v1

Ms2ger, what about that patch? :)
Assignee: nobody → mounir
Attachment #597895 - Flags: review?(Ms2ger)
Looks fine on first sight, but I want to cross-check more carefully with the spec. I hope to get to it tomorrow.
Comment on attachment 597895 [details] [diff] [review]
Patch v1

Review of attachment 597895 [details] [diff] [review]:

r=me with those changes

::: content/html/content/src/nsHTMLOptionElement.cpp
@@ +208,4 @@
> +  // Get the options from the select object.
> +  nsCOMPtr<nsIDOMHTMLOptionsCollection> options;
> +  selectElement->GetOptions(getter_AddRefs(options));

nsHTMLOptionCollection* options = selectElement->GetOptions();

@@ +229,2 @@
>      }
>    }

How about

PRInt32 index = 0;
if (NS_SUCCEEDED(options->GetOptionIndex(this, 0, true, &index)) {
  *aIndex = index;
Attachment #597895 - Flags: review?(Ms2ger) → review+

Comment 14

5 years ago
(In reply to Ms2ger from comment #13)
> PRInt32 index = 0;
> if (NS_SUCCEEDED(options->GetOptionIndex(this, 0, true, &index)) {
>   *aIndex = index;
> }

Given that index shouldn't be set when there is a failure and a failure shouldn't happen, I think we can do:
return options->GetOptionIndex(this, 0, true, aIndex);

Ok with that Ms2ger?
That sounds a little scary, but I can live with it if you add those givens to the documentation for GetOptionIndex.
Oh, and you can invent a better commit message ;)


5 years ago
Flags: in-testsuite+
Target Milestone: --- → mozilla13


5 years ago
Attachment #597895 - Flags: checkin+
Last Resolved: 5 years ago
Resolution: --- → FIXED
Keywords: dev-doc-needed
I updated
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.