selectedcontent element mutation record test is wrong

[annevk]

The replace all primitive uses a single record for additions and removals. With this change my prototype passes the test.

I strongly suspect <option selected><span>span</option> three</option> is also a bug in this test, but I didn't want to change that at the same time.

[josepharhar]

Thanks for looking at this. The reason that there are two separate mutations in chromium is because when the third option, <option selected> is parsed and inserted, it gets cloned into <selectedcontent> two times:

1. During the option element insertion steps, before the parser has appended children to the option element, because the option is selected. This results in a mutation which just removes all nodes from the selectedcontent element because the option element is empty.
2. When the option element is done parsing its children because it is selected.

This doesn't match the spec because the option element insertion steps just say to run the selectedness setting algorithm which doesn't clone anything into the selectedcontent element, but I'm not sure if that really is good behavior.

Consider the following:

<select id=select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option>one</option>
</select>
<script>
  const option = document.createElement('option');
  option.setAttribute('selected', '');
  option.textContent = 'two';
  select.appendChild(option);
</script>

I think that the selectedcontent element definitely needs to be updated for the newly selected option in this case, which can only be done through the option element insertion steps, right?

I think this was an oversight when I wrote this part of the spec, unless I'm missing something. I think it would probably be best to update the selectedcontent element in the selectedness setting algorithm, what do you think?

[annevk]

My prototype handles that as part of "finishParsingChildren". I don't really care strongly what we do I suppose, but I do get the feeling we lack a lot of test coverage (what if your example was created imperatively for instance) as there's only a minimal set of tests for this new element. And also that the specification is somewhat incomplete.

(I spotted Chromium setting <selectedelement>'s disabled to false upon removal, but there's nothing that tests for this, even though you might be able to. Although that also depends on whether or not we start guarding everything with "is connected" checks.)

[josepharhar]

Thanks, I am rewriting the test here and will take a closer look at the spec and chromium implementation here.

[josepharhar]

This PR should fix the selectedness setting issue: whatwg/html#11890