web-platform-tests/wpt merge_pr_48845

on GitHub

DOM: Make selection test fail accurately

A selection preservation test for the moveBefore() API was added in
https://crrev.com/c/5725934 which passes falsely / incorrectly.
Selection preservation has not been fully implemented in Chromium, but
this test passes for two reasons:

1. Inside the old parent from which the moved element is moved, there
   is no text except for the moved text. This appears to have a weird
   side-effect — if we moveBefore() from a parent that is otherwise
   empty, the selection returned by the getSelection() API appears
   to have the anchorNode still set to the new freshly-moved node.
   On the contrary, if you move text from a parent that has plenty of
   other preceding text, the selection returned from getSelection()
   after the move sticks to the preceding text, and indicates that
   the selection API does not preserve properly across moves.
2. Before the moveBefore() API is called,
   getSelection().anchorNode is called. This ALSO has a weird
   side-effect of computing the DocumentCachedRange(), and since
   we have implemented the behavior to NOT update Ranges during an
   atomic move (in https://crrev.com/c/5725934), the cached range
   from before moveBefore() persists and deceptively indicates that
   selection has been preserved, when it hasn't been. Specifically,
   the cache range was indeed "preserved" by virtue of not being
   modified during the move, but in reality the visual (highlighted)
   selection was not preserved, and becomes out-of-sync with the
   cached Range selection returned by the selection API. By NOT
   calling getSelection() before the move, we ensure that we do not
   generate a cached selection Range, and by only calling
   getSelection() after the move, we force the Selection API to
   generate a cached selection Range based off of the actual visual
   selection, which gives us a truer picture of what the visual
   selection (the stuff that the user sees) actually is.

The test that this CL modifies accidentally relied on these two quirks
above, which made the test pass even though true selection preservation
was not implemented. This CL updates the test to not lean on these
quirks, so that it fails appropriately. A subsequent CL will implement
visual selection preservation properly, ensuring that the Selection
API's cached selection Range can never get out of sync with the visual
selection. That CL will add more tests and mark this one as passing.

R=nrosenthal@chromium.org

Bug: 40150299
Change-Id: Ifba24444f0c067643df650c69fb631fd94273d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5966878
Commit-Queue: Dominic Farolino dom@chromium.org
Reviewed-by: Mason Freed masonf@chromium.org
Cr-Commit-Position: refs/heads/main@{#1374916}