selectedcontent removing steps vs pagehide (and unload)

[annevk]

What is the issue with the HTML Standard?

As part of implementing the selectedcontent element in WebKit we believe we encountered an issue. Namely that the removing steps itself end up itself removing nodes, which can result in the pagehide event, whose listeners would now have access to the DOM during an inconsistent state.

I think at least for that case we need something akin to post-removing steps perhaps or maybe custom element reaction timing?

(See also this older issue discussing some of the issues with these events: #4611.)

cc @josepharhar @noamr @domfarolino @mfreed7 @rniwa @smaug----

[josepharhar]

Thanks for bringing this up. The reason that the removal steps run cloning is because it may change which selectedcontent becomes the primary one, and we want to keep the primary one up to date. This didn't matter in the original implementation which always updated all selectedcontent elements, but we changed it to only track one "primary" selectedcontent element:

• Define the <selectedcontent> element #10633 (comment)
• https://chromium.googlesource.com/chromium/src/+/f8190777fa80312a588f06a7b6ba2cf3bd9897a7

In my opinion, keeping the newly primary selectedcontent element up to date in the case that the primary selectedcontent element is removed is not a use case we should guard against because there is no use case to append multiple selectedcontent elements to a select and then remove the first one, which would be another way to justify removing the selectedcontent element removal steps.

So I think we have two options to address this issue:

1. Clone the selected option into every selectedcontent element descendant of the select element instead of the first one in tree order.
2. Drop the selectedcontent removal steps without any other changes because it guards against a case that isn't important.

[dbaron]

Two side issues here to consider as well, which apply if we keep the removing steps:

• use of oldParent in HTML element removing steps is sometimes wrong #12098
• we probably also need moving steps here. (I suspect this is a case of two PRs being developed around the same time and the interaction between them being missed.)

For the issue here, I personally prefer @josepharhar's first option above, keeping all the <selectedcontent> elements up-to-date rather than just one.

[smaug----]

Where would "Clone the selected option into every selectedcontent" exactly happen? That itself may run scripts.

[dbaron]

The cloning would be a change to https://html.spec.whatwg.org/multipage/form-elements.html#update-a-select's-selectedcontent so that it iterates a list of selectedcontent rather than just updating one of them as it does today. (The removing steps and parts of the post-connection steps are there to handle the case of insertions/removals changing which <selectedcontent> is the one that gets updated, and if we update all of them we can avoid dealing with insertions/removals changing the state of a different <selectedcontent>.)

[smaug----]

yeah, ok, looking at the callers of 'update a select's selectedcontent', I think I could live with (1). It is definitely better than trying to figure out how to make removing steps safer.