1421260 - option.selected suddenly changes to true for no reason

Status: NEW

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

Description

[Andrea Giammarchi]

Attachment: firefox-bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

I have used a diffing algorithm to update a <SELECT> element with fresh new options.

You can test the break down of the issue in this CodePen:
https://codepen.io/WebReflection/pen/WXaeWj?editors=0010


Actual results:

The <SELECT> shows a different selected options compared to any other browser. Nobody set the option.selected = true to the first item of the select.


Expected results:

The select should accept new option nodes, eventually flag as non selected the previously live selected one and **never** set selected = true to random nodes.

Comment 1

[Andrea Giammarchi]

Thanks for moving on already. I'd like to add that there are many libraries using diff-algorithms and having a select that suddenly changes selected value might be a security issue/concern too for real-world code out there.
I haven't checked it as security concern but I wouldn't underestimate possible implications.
Thanks.

Comment 2

[Andrew Overholt [:overholt]]

Jessica knows more about <select> than I do so I'll needinfo her.

Anne, is it spec-compliant to set option.selected = true for the first item of the <select> element?

Comment 3

[Andrea Giammarchi]

Andrew, even if that's the case, the demo code I've shown doesn't make sense.

Let me try to describe what happens:

A live select has 3 options, one of them is selected and has explicit selected = true. Let's call this option "bob".

A *non* selected option, let's call it "lenny", is pre-pended to the list of live options.
Now the select has 4 options and "bob", that was selected before, is still selected. All others aren't, including "lenny".

That means, if a new option is appended and there is a selected one, nothing changes, the selected is still selected.
I assume the same is if you append a new non-selected option.

Now ... a new option with explicitly `selected = true` info is inserted between the first one, "lenny", and the second option, previously there.

The one that was already selected, "bob", becomes non-selected.
This is what every other browser does and it makes sense: an explicitly selected option is appended, drop the previously selected one.

So far, so good ... the absurdity though, is that the appended selected option is still `selected === true`.
But why on earth is "lenny" now selected?

Basically, inserting a selected option within options drops the previously selected one and makes the first one selected, without dropping the currently selected one.

If this is expected, this is a bug in the specification.

Comment 4

[Andrea Giammarchi]

"without dropping the currently selected one"

to clarify that, I am expecting the behavior Chrome and Safari have in the demo code.

The selected option appended later on should be the only selected one in the list of options.

The first one should **not** get promoted as selected, since there is another one already explicitly selected in there.

Comment 5

[Anne (:annevk)]

It seems Firefox does not implement this bit from the HTML Standard:

> If the multiple attribute is absent, whenever an option element in the select element's list of options has its selectedness set to true, and whenever an option element with its selectedness set to true is added to the select element's list of options, the user agent must set the selectedness of all the other option elements in its list of options to false.

Possibly there's some confusion with later requirements around manipulating the contents of select elements, but nothing supports Firefox's behavior.

Comment 6

[Jessica Jong [:jessica] (inactive)]

Also, this:

> If two or more option elements in the select element's list of options have their selectedness set to true
>  Set the selectedness of all but the last option element with its selectedness set to true in the list of options in tree order to false.

So, yes, it's a bug in Firefox. Let me get back to this later.

Comment 7

[Jessica Jong [:jessica] (inactive)]

I remembered when I was debugging, it was because we call CheckSelecSomething [1] in HTMLSelectElement::SetOptionsSelectedByIndex, so maybe we should call the function with mask NO_RESELECT somewhere.
A little hint for anyone who is taking this bug in the future. :)


[1] https://searchfox.org/mozilla-central/rev/2031c0f517185b2bd0e8f6f92f9491b3410c1f7f/dom/html/HTMLSelectElement.cpp#961

Comment 8

[Marcos Caceres [:marcosc]]

I’ll take this one, but will do it in my spare time. Setting to P3 until I actually start working on it.

Comment 9

[Marcos Caceres [:marcosc]]

No longer working on DOM Team, so removing myself.