Option selectedness when all children are removed from select

[josepharhar]

What is the issue with the HTML Standard?

Consider the following:

<select id=select>
  <option id=one>one</option>
  <option id=two>two</option>
</select>
<script>
const one = document.getElementById('one');
const two = document.getElementById('two');
select.innerHTML = '';
select.appendChild(one);
select.appendChild(two);
console.log(select.value);
</script>

In webkit, "one" is the selected option. In firefox, "two" is the selected option. In chromium, it used to be "one" until I unknowingly changed it to "two", and now I have to change it back to the webkit behavior of "one" due to a regression affecting multiple sites.

In webkit and pre-regression chromium:
The selectedness setting algorithm runs after all of the options are removed in HTMLSelectElement::ChildrenChanged, so option one stays selected and option two stays not-selected.

In firefox, which I think matches the spec as well:
The selectedness setting algorithm runs in between option removals, which means that one gets removed and stays selected, then the selectedness setting algorithm makes option two selected, then option two gets removed and stays selected. When the options are re-appended, inserting option two which is selected causes option one to become un-selected.

I don't think that there is a spec equivalent of the chromium/webkit ChildrenChanged with kAllChildrenRemoved which allows us to run something after all of the children have been removed from the select element, is there?

Another idea I had to fix this was to just set selection back to an initial state any time an option element gets removed, meaning that it selectedness gets set to true if it has the selected attribute, otherwise false. However I'm hesitant to do this in case it breaks more sites.

[annevk]

It seems <option>.selected is different as well. (Or does your Chromium change undo that as well?)

[annevk]

I guess what WebKit does is indeed the other option you considered? Because when I disable all "children changed" code paths I still get "one" here.

cc @whatwg/forms

[josepharhar]

Ah thanks for looking at option.selected, I didn't realize the webkit behavior there. You're correct that webkit seems to be doing the other option I considered, so perhaps I could try implementing the webkit behavior. I wonder exactly how webkit is setting selectedness to false. I quickly skimmed HTMLSelectElement.cpp and HTMLOptionElement.cpp and didn't see anything obvious.

[annevk]

Not sure. It seems if you call <option>.selected earlier, you get a slightly different result. That it differs depending on observation seems like a bug.

[annevk]

There is one test I end up failing when I fully remove all "children changed" code paths and I'm not sure how to make it pass without them. From https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-select-element/inserted-or-removed.html it's this bit:

test(() => {
  const target = document.querySelector("#by-dom");
  // ...
  const optgroup = document.createElement('optgroup');
  const option3 = document.createElement('option');
  option3.defaultSelected = true;
  option3.textContent = 'First';
  const option4 = document.createElement('option');
  option4.defaultSelected = true;
  option4.textContent = 'Second';
  optgroup.appendChild(option3);
  optgroup.appendChild(option4);
  target.appendChild(optgroup);
  assert_equals(target.selectedOptions[0].textContent, 'Second');
}, 'The last selected OPTION should win; Inserted by DOM API');

The problem is that when we run the insertion callback for option3, we mark that as the selected option and therefore option4 gets deselected because it's already in the tree at that point. And you can't fix this by having insertion behavior for optgroup elements, because when that callback runs, the callback for the option elements hasn't run yet and they won't have a select element owner yet.

For now in WebKit/WebKit#51940 I've decided to not regress this test by keeping our existing "children changed" code, but curious to hear what people make of this. Something probably has to give.

cc @rniwa

[josepharhar]

Not sure. It seems if you call <option>.selected earlier, you get a slightly different result. That it differs depending on observation seems like a bug.

I see, that is odd. I wonder what's going on.

The problem is that when we run the insertion callback for option3, we mark that as the selected option and therefore option4 gets deselected because it's already in the tree at that point. And you can't fix this by having insertion behavior for optgroup elements, because when that callback runs, the callback for the option elements hasn't run yet and they won't have a select element owner yet.

In chromium, each option will have its insertion steps called twice: once when they are inserted into the optgroup, and a second time when the optgroup is appended to the select element.

During the first insertion into the optgroup, the selectedness of each option should remain true due to the defaultSelected.

During the second insertion, option 3 runs its insertion steps and then option 4 runs its insertion steps. It would make sense that option 3 deselects the other options during its insertion (via the selectedness setting algorithm) and therefore makes option 4 not get selected, but it looks like we have some code which prevents that from happening: since option 4 hasn't had its insertion steps run yet which assigned a cached nearest ancestor select, it doesn't get deselected.

We could modify the selectedness setting algorithm to run like this by checking each option's cached nearest ancestor select.

Does this make sense? Does that sound like a good spec change?