Specify the behavior when DOM mutation occurs across shadow-crossing selection

[rniwa]

We should specify the behavior when DOM trees are mutated (e.g. shadow host is removed) when selection cross shadow boundaries.

[annevk]

I think this is essentially what I mentioned in https://github.com/w3c/selection-api/issues/161#issue-1503058584 which references https://github.com/WICG/webcomponents/issues/79#issuecomment-972726532.

Let's think about this a bit:

• We want a new selection live range whose boundary points can be in distinct trees so we can have text selection across the shadow boundary. (Though ultimately they still need to have some kind of shared shadow-including root.)
  • This needs to be updated correctly by the various node tree mutation algorithms.
  • This should not be exposed to script. (Instead we hand out static ranges.)
• We want a selection live range to point back to a Selection. Currently Selection is mostly defined in terms of a single range, but this might change and it makes sense to let Selection be responsible for rendering the range when it changes and such.
  • I guess ideally after each mutation we invoke some kind of "update selection" algorithm, although currently that does not exist.
• Selection needs to be reworked to hold onto this new selection live range and not return it directly.
  • What might be tricky is that if someone accesses getRange(0) and manipulates that, this selection live range needs to be updated as well (or perhaps thrown away). We need to be careful not to introduce loops there.

@mfreed7 @rniwa @smaug---- thoughts?

[mfreed7]

Similar to my reply on #79, I agree.

Your summary above sounds exactly right to me. The devil is in the details, but the broad strokes look correct.

What might be tricky is that if someone accesses getRange(0) and manipulates that, this selection live range needs to be updated as well (or perhaps thrown away). We need to be careful not to introduce loops there.

Seems like that operation (manipulation of a live range) should go through the same "update selection" algorithm which should take care of the details.

[annevk]

Seems like that operation (manipulation of a live range) should go through the same "update selection" algorithm which should take care of the details.

That would mean we have multiple ranges associated with the selection representing the same conceptual range within the selection.

Maybe instead the "public selection live range" (getRange(0)) should point directly to the selection live range and update that, which then updates the selection. With multiple ranges that would still work, with each selection live range having its own public selection live range.

The most difficult part here is probably defining the "selection live range".

[smaug----]

This needs to be updated correctly by the various node tree mutation algorithms.

That is the tricky bit. Not only we need to handle mutations in one tree but I believe also changes to slotting should affect selection.

[masayuki-nakano]

I wrote a test to check the behavior of a selection range which is in a shadow DOM and after the host is removed. Currently, Chrome keeps the range as a selection range without modifying the range in the shadow. Firefox removes the range from Selection without updating the range. (It seems that Safari collapse the selection range to the removed node position, but the test fails at checking the stored range behavior.)

I changed the Firefox's behavior as so for consistency with https://github.com/whatwg/dom/issues/1274 and https://github.com/w3c/selection-api/issues/175, but could be reasonable to make the selection range cloned (to avoid unexpected range update for the referrers of the Range object) and collapsed to the parent DOM tree (like as in the light DOM, i.e., like Safari).