Skip to content

Refine when selectedcontent elements are updated - #13005

Open
annevk wants to merge 1 commit into
mainfrom
annevk/selectedcontent-follow-ups
Open

annevk wants to merge 1 commit into
mainfrom
annevk/selectedcontent-follow-ups

Conversation

@annevk

@annevk annevk commented Sep 29, 2026 •

Copy link
Copy Markdown
Member

This is a follow-up to #12263 that addresses the remaining cases where selectedcontent elements were updated too little or too much:

  • Inserting an option element that causes another option element to become selected now updates selectedcontent elements. This happens when the select element has no selected option, e.g., after setting selectedIndex to -1.
  • Inserting a select element that already contains option elements now updates its selectedcontent elements once, rather than again from the post-connection steps of its selected option element.
  • The microtasks queued to update selectedcontent elements after option elements are removed or moved are now coalesced per select element, and do nothing if the selectedcontent elements were updated in the meantime. The same goes for moving a selectedcontent element.
  • The microtask queued by the selectedcontent moving steps now determines the select element when it runs, rather than when it is queued.
  • Moving a selectedcontent element no longer updates it when its select element and disabledness do not change, e.g., when an ancestor of the select element is moved.
  • Removing a selectedcontent element now recalculates its disabledness.
  • Setting the selected IDL attribute of an option element only updates selectedcontent elements when selectedness changes.

This also removes "ask for a reset" and "update descendant selectedcontent elements for an option", which would otherwise each have a single caller.

Tests: web-platform-tests/wpt#63153

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


/form-elements.html ( diff )

@annevk

annevk commented Sep 29, 2026

Copy link
Copy Markdown
Member Author

@josepharhar @jnjaeschke I noticed a couple more cases. Once some of my WebKit work lands I'll upload tests for this as well.

@annevk annevk added the topic: select The <select> element label Sep 29, 2026
This is a follow-up to #12263 that addresses the remaining cases where selectedcontent elements were updated too little or too much:

* Inserting an option element that causes another option element to become selected now updates selectedcontent elements. This happens when the select element has no selected option, e.g., after setting selectedIndex to -1.
* Inserting a select element that already contains option elements now updates its selectedcontent elements once, rather than again from the post-connection steps of its selected option element.
* The microtasks queued to update selectedcontent elements after option elements are removed or moved are now coalesced per select element, and do nothing if the selectedcontent elements were updated in the meantime. The same goes for moving a selectedcontent element.
* The microtask queued by the selectedcontent moving steps now determines the select element when it runs, rather than when it is queued.
* Moving a selectedcontent element no longer updates it when its select element and disabledness do not change, e.g., when an ancestor of the select element is moved.
* Removing a selectedcontent element now recalculates its disabledness.
* Setting the selected IDL attribute of an option element only updates selectedcontent elements when selectedness changes.

This also removes "ask for a reset" and "update descendant selectedcontent elements for an option", which would otherwise each have a single caller.

Tests: TBD.
@annevk
annevk force-pushed the annevk/selectedcontent-follow-ups branch from d201e93 to 2fcaa59 Compare September 30, 2026 14:06
@annevk
annevk marked this pull request as ready for review October 1, 2026 05:24
@annevk
annevk requested review from josepharhar and zcorpan October 1, 2026 05:25
annevk added a commit to annevk/WebKit that referenced this pull request Oct 2, 2026
https://bugs.webkit.org/show_bug.cgi?id=325898

Reviewed by NOBODY (OOPS!).

Align with whatwg/html#13005

Inserting, removing, or moving an <option> now updates <selectedcontent> when
that causes another option to become selected, which happens when the <select>
has no selected option. Inserting an <option> only updates <selectedcontent>
when it changes the selected option. To detect this, <select> remembers which
option it last cloned into its <selectedcontent> elements. Inserting multiple
options together thus updates <selectedcontent> once. An <option> whose <select>
does not change, as when inserting a <select> that already contains options,
leaves updating to the <selectedcontent> itself.

The microtasks that update <selectedcontent> after removing or moving an
<option>, or moving a <selectedcontent>, are now coalesced and do nothing if the
<selectedcontent> was updated in the meantime.

A moved <selectedcontent> now finds its <select> when the queued microtask runs,
and is not updated at all when it stays enabled in the same <select>, for
instance when an ancestor of the <select> is moved.

Removing a <selectedcontent> now recalculates whether it is disabled.

Test: imported/w3c/web-platform-tests/html/semantics/forms/the-select-element/customizable-select/selectedcontent-queued-update.html

Tests upstream: web-platform-tests/wpt#63153
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic: select The <select> element

Development

Successfully merging this pull request may close these issues.

1 participant