Clone into all descendant selectedcontent elements by josepharhar · Pull Request #12263 · whatwg/html

josepharhar · 2026-03-16T02:23:25Z

This PR changes several things:

Instead of the first selectedcontent element in DOM order staying up to date, now all descendant selectedcontent elements of the select element will be kept up to date.
Rewrites the selectedness setting algorithm to prevent setting selectedness of options which haven't had their insertion steps run yet in order to match implementations and to update selectedcontent elements.
Creates a list of selectedcontent elements to update before doing actual DOM operations.

Fixes #12096
Fixes #11880
Fixes #11883
Fixes #11825

At least two implementers are interested (and none opposed):
- Chromium
- …
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
- Chromium: Already implemented
- Gecko: …
- WebKit: …
Corresponding HTML AAM & ARIA in HTML issues & PRs: not needed
MDN issue is filed: not needed because the existing mdn article doesn't mention anything about having multiple selectedcontent elements inside a select
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

This PR improves the "clear a select's non-primary selectedcontent elements" algorithm by making it create a list of selectedcontent elements to modify separately from modifying them in order to prevent the list of elements to change while iterating. Fixes whatwg#11880

This PR makes sure that the contents of the selectedcontent element stay up to date when the selected option is changed in the selectedness setting algorithm. This issue was found here: web-platform-tests/wpt#55849 (comment)

In order to make the selectedness setting algorithm match implementations, this PR makes the selectedness setting algorithm avoid changing the selectedness of option elements which haven't ran their insertion steps yet by checking whether the options have their cached nearest ancestor select element assigned yet or not. This was discussed here: whatwg#11825

…electedcontentredo

…edcontentredo

…contentredo Merged the PRs, now I need to do the selectedcontent rewrite to clone into all descendant selectedcontent elements.

annevk

Thanks @josepharhar! Here's some minor editorial feedback to start. Will try to verify these changes by implementing them.

annevk · 2026-03-25T09:40:38Z

+   <li><p>Let <var>descendantSelectedcontents</var> be « ».</p></li>

-   <li><p>Let <var>option</var> be the first <code>option</code> in <var>select</var>'s <span
-   data-x="concept-select-option-list">list of options</span> whose <span
-   data-x="concept-option-selectedness">selectedness</span> is true, if any such <code>option</code>
-   exists, otherwise null.</p></li>
+   <li>
+    <p>For each <var>descendant</var> of <var>select</var>'s <span
+    data-x="descendant">descendants</span>:</p>

-   <li><p>If <var>option</var> is null, then run <span>clear a <code>selectedcontent</code></span>
-   given <var>selectedcontent</var>.</p></li>
+    <ol>
+     <li><p>If <var>descendant</var> is a <code>selectedcontent</code> element, then <span
+     data-x="list append">append</span> <var>descendant</var> to
+     <var>descendantSelectedcontents</var>.</p></li>
+    </ol>
+   </li>


We don't need a loop for this. We can state this declaratively:

Let selectedContents be select's descendants that are selectedcontent elements, in tree order.

Also, I have a more substantive question here. Why doesn't this skip disabled selectedcontent elements immediately?

I think the selectedcontent-nested.html test currently expects this, but it seems wasteful and best avoided.

We don't need a loop for this. We can state this declaratively:

Done, thanks

Also, I have a more substantive question here. Why doesn't this skip disabled selectedcontent elements immediately?

Disabled selectedcontents will be skipped deeper in the algorithms called by this one - "clone an option into a selectedcontent" and "clear a selectedcontent" both check if the selectedcontent is disabled before modifying the DOM, and return early.

We could add a step to skip disabled selectedcontents here, but it would functionally be redundant, unless I'm misreading something. What do you think? Can we leave it as-is?

Can you explain https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-select-element/customizable-select/selectedcontent-nested.html then? Isn't parentSelectedcontent disabled once it is inserted?

Ok, yes I see how it would change the behavior to check if the selectedcontent elements are disabled before adding them to the list. I'll change the spec here and update the WPT.

This changes the behavior when selecting a new option in the case that there are nested selectedcontent elements inside the select. Before, the disabled selectedcontent would get cloned, but now it won't. Context: whatwg/html#12263 (comment) Bug: 458113204 Change-Id: I9afd550f21787b7daefb48c5a76712b5899e5b42

This changes the behavior when selecting a new option in the case that there are nested selectedcontent elements inside the select. Before, the disabled selectedcontent would get cloned, but now it won't. Context: whatwg/html#12263 (comment) Bug: 458113204 Change-Id: I9afd550f21787b7daefb48c5a76712b5899e5b42 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7737623 Reviewed-by: David Grogan <dgrogan@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1611875}

Modifying the DOM by updating selectedcontent elements during insertion or removal steps is bad for security reasons. We already removed the selectedcontent element removal steps which was one way this can happen, but the option's InsertedInto and RemovedFrom methods may change which option is selected, which will synchronously update the selectedcontent element. This patch fixes this by moving the selectedcontent updating to the post-insertion steps for insertion, and by using a microtask to update on removal if needed. This matches the behavior in the spec PR: whatwg/html#12263 Bug: 458113204 Change-Id: I42bb94c6eace93445cfbc816529e42ca8a561b94 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7745871 Reviewed-by: David Baron <dbaron@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1622241}

josepharhar · 2026-05-07T16:16:33Z

@annevk @jnjaeschke do yall have any more feedback on this PR?

…nsertion/removal steps, a=testonly Automatic update from web-platform-tests Don't update selectedcontent in option insertion/removal steps Modifying the DOM by updating selectedcontent elements during insertion or removal steps is bad for security reasons. We already removed the selectedcontent element removal steps which was one way this can happen, but the option's InsertedInto and RemovedFrom methods may change which option is selected, which will synchronously update the selectedcontent element. This patch fixes this by moving the selectedcontent updating to the post-insertion steps for insertion, and by using a microtask to update on removal if needed. This matches the behavior in the spec PR: whatwg/html#12263 Bug: 458113204 Change-Id: I42bb94c6eace93445cfbc816529e42ca8a561b94 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7745871 Reviewed-by: David Baron <dbaron@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1622241} -- wpt-commits: 8116dc1ced751ff3a62c58e020f3d7d0ad61553b wpt-pr: 59528

annevk · 2026-05-11T13:44:05Z

There's also an existing issue with moving option elements apparently. Those currently don't update the selectedcontent element either leading to stale state on both sides. Presumably that's not what we want?

annevk

The moving steps also haven't been addressed? And I believe the current set of algorithms would give us the Firefox outcome on #11825. Is that intentional?

…nsertion/removal steps, a=testonly Automatic update from web-platform-tests Don't update selectedcontent in option insertion/removal steps Modifying the DOM by updating selectedcontent elements during insertion or removal steps is bad for security reasons. We already removed the selectedcontent element removal steps which was one way this can happen, but the option's InsertedInto and RemovedFrom methods may change which option is selected, which will synchronously update the selectedcontent element. This patch fixes this by moving the selectedcontent updating to the post-insertion steps for insertion, and by using a microtask to update on removal if needed. This matches the behavior in the spec PR: whatwg/html#12263 Bug: 458113204 Change-Id: I42bb94c6eace93445cfbc816529e42ca8a561b94 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7745871 Reviewed-by: David Baron <dbaronchromium.org> Reviewed-by: Joey Arhar <jarharchromium.org> Commit-Queue: Joey Arhar <jarharchromium.org> Cr-Commit-Position: refs/heads/main{#1622241} -- wpt-commits: 8116dc1ced751ff3a62c58e020f3d7d0ad61553b wpt-pr: 59528 UltraBlame original commit: 86fb81e4e646ca7e6da3fa87d0d72010474fb780

josepharhar · 2026-05-13T14:29:11Z

Thanks, I am working on moving steps right now for option and selectedcontent elements, and I'll update this PR accordingly soon.

And I believe the current set of algorithms would give us the Firefox outcome on #11825. Is that intentional?

I think this problem exists before and after this PR and this PR does not intend to change this behavior. Is there something in here in particular that it looks like this PR is changing with regards to this behavior?

josepharhar · 2026-05-13T16:52:27Z

Ok, I pushed a change to make the moving steps for options and selectedcontent elements update selectedcontent elements if appropriate after a microtask.

josepharhar · 2026-05-28T20:34:55Z

Is there anything else I can do to get this PR merged? I'd like to ship the changes in chromium.

… changed in theory

…no more post-insertion needed

annevk · 2026-06-05T08:39:10Z

The last two commits I pushed have behavioral changes:

It seemed that the post-connection steps didn't recalculate disabled. With that commit they do.
I also wanted to see what it would look like if we relied on microtasks entirely as that means we don't need post-connection steps. This looks quite attractive to me and from the earlier discussion I'm not sure we feel that strongly about it being synchronous. The main use cases are about being able to style it differently which this shouldn't impact at all.

Thoughts?

josepharhar · 2026-06-09T22:44:07Z

Thanks Anne, this looks great! I am ok with using microtasks more often, and it looks like when actually choosing an option the selectedcontent element is still updated synchronously, right?

josepharhar · 2026-06-11T17:41:12Z

  </div>

-  <div algorithm>
-  <p>When an <code>option</code> element is popped off the <span>stack of open elements</span> of an


@annevk is this not needed anymore because of the microtasks?

josepharhar added 15 commits November 4, 2025 13:02

Update selectedcontent in selectedness setting

5d4835a

This PR makes sure that the contents of the selectedcontent element stay up to date when the selected option is changed in the selectedness setting algorithm. This issue was found here: web-platform-tests/wpt#55849 (comment)

remove duplicate li

dd2258a

inline one step list

85ef15c

change variable names

80e0785

nits

dfec190

Merge branch 'main' into selectednesssetting

6b749d8

readability improvements

af049b7

rename variable

a51df08

Merge remote-tracking branch 'origin/selectedcontentiterating' into s…

8f410a4

…electedcontentredo

Merge remote-tracking branch 'origin/selectednesssetting' into select…

12e587c

…edcontentredo

Merge remote-tracking branch 'origin/selectednesscheck' into selected…

ff783fa

…contentredo Merged the PRs, now I need to do the selectedcontent rewrite to clone into all descendant selectedcontent elements.

Update all descendant selectedcontent elements

96c2613

re-merge selectedness setting algorithm

4b75042

This was referenced Mar 16, 2026

Build list of selectedcontent elements to clear #11891

Closed

selectedcontent removing steps vs pagehide (and unload) #12096

Open

Update selectedcontent in selectedness setting #11890

Closed

Use cached select in selectedness setting algorithm #12083

Closed

annevk reviewed Mar 25, 2026

View reviewed changes

josepharhar added 5 commits March 31, 2026 14:25

inline loop

175b54c

in->of

5088085

,->;

a09e79c

Merge branch 'main' into selectedcontentredo

dae7e55

build list with only enabled selectedcontents

d095eb6

chromium-wpt-export-bot mentioned this pull request Apr 8, 2026

Check disabled when building selectedcontent list web-platform-tests/wpt#59059

Merged

chromium-wpt-export-bot mentioned this pull request Apr 29, 2026

Don't update selectedcontent in option insertion/removal steps web-platform-tests/wpt#59528

Merged

only queue microtask if there is a selectedcontent element

57b0f75

josepharhar mentioned this pull request May 8, 2026

Support <selectedcontent> in <select multiple> #12430

Open

6 tasks

annevk added the topic: select The <select> element label May 11, 2026

annevk reviewed May 11, 2026

View reviewed changes

address review comments

9770048

annevk reviewed May 12, 2026

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

small fixes

d55c0ca

update selectedcontent after moving steps

fb7140c

Merge branch 'main' into selectedcontentredo

d68af3e

annevk added 3 commits June 5, 2026 10:07

nits

b5c0c48

make post-connection steps recalculate as well as disabled could have…

5a4e27d

… changed in theory

This demonstrates what it would look like if we only did microtasks; …

a35e96a

…no more post-insertion needed

any descendant selectedcontent check

eee149c

josepharhar commented Jun 11, 2026

View reviewed changes

Conversation

josepharhar commented Mar 16, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

annevk Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

annevk Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

josepharhar Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

annevk Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

josepharhar Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

josepharhar commented May 7, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

annevk commented May 11, 2026

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josepharhar commented May 13, 2026

Uh oh!

josepharhar commented May 13, 2026

Uh oh!

josepharhar commented May 28, 2026

Uh oh!

annevk commented Jun 5, 2026

Uh oh!

josepharhar commented Jun 9, 2026

Uh oh!

josepharhar Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

josepharhar commented Mar 16, 2026 •

edited by pr-preview Bot

Loading