selectedcontent post-connection steps did not break out of the loop

[annevk]

And also has an unused ancestor variable.

---

/form-elements.html ( diff )

[dbaron]

If I'm understanding things correctly, I think there's an undesirable side-effect of this break. (I got here from reviewing @josepharhar's CL that implements this behavior.)

In particular (and hopefully I'm rememembering how all this stuff works correctly, since I'm not checking all the pieces with the spec as I go along), if we start with:

<select id="s">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option selected>One</option>
</select>

then the <selectedcontent> will initially be filled with "One".

Now, suppose that JS comes along and does:

  const sc = document.createElement("selectedcontent");
  const o = document.createElement("option");
  o.append(sc);
  document.getElementById("s").prepend(o);

At this point, I think we're going to:

1. invoke these post-connection steps being modified in this PR
2. break at this break statement
3. Because of that break, leave the existing <selectedcontent> element with the "One" contents inside of it.

However, after this change, the "get a select's enabled selectedcontent" algorithm will now return null, because the <selectedcontent> added by the JS above is disabled. This means that as a result of this break, we'll be leaving the previously-working <selectedcontent> element with stale content, permanently. That seems pretty weird to me (though I admit that every case where a <selectedcontent> is disabled is effectively an error case).

[dbaron]

That said, now that I understand @josepharhar's comment on the rationale here, maybe we do need to break if we hit an ancestor selectedcontent, because otherwise the algorithm will go into an infinite loop. So maybe we want to change this so this particular break is only when the ancestor is a selectedcontent element?

[josepharhar]

So maybe we want to change this so this particular break is only when the ancestor is a selectedcontent element?

I tried implementing this, but it still encountered an infinite loop in one of the test cases.

[annevk]

@josepharhar maybe you can propose how you want to address this? Because as-is there's clearly issues too. At least I couldn't implement the specification text in WebKit...

[josepharhar]

I think we should address this by leaving the case that David described broken. This is what it looks like after running the script:

<select>
  <option>
    <selectedcontent></selectedcontent>
  </option>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option selected>one</option>
</select>

I don't know why anyone would want to put a second selectedcontent in an option like this. If we leave it "broken" by not updating any of the selectedcontent elements, I think that's fine.

[annevk]

Ok, I've now made the PR reflect what you wanted and also fixed a couple other nits. I haven't yet checked your tests. Can you review again? And maybe David too if he has the time?

[josepharhar]

Thanks, the current state of this PR matches the logic in my chromium patch. I asked David to check again as well.

[annevk]

I added another change here to also early return for disabled selectedcontent elements when they are removed. There's no real reason to update the select's current selectedcontent again when that happens. (That is already tested to some extent by web-platform-tests/wpt#55849 (both before and after my changes as Chromium does something similar, but more involved).)