Re: [w3c/selection-api] Change Selection to be associated with a composed live range (PR #345)

@domfarolino commented on this pull request.



> @@ -546,24 +566,18 @@ <h2>
             <var>newFocus</var> be the <a>boundary point</a> (<var>node</var>,
             <var>offset</var>).
             </li>
-            <li>Let <var>newRange</var> be a new <a>range</a>.
-            </li>
-            <li>If <var>node</var>'s [=tree/root=] is not the same as the
-            [=this=]'s <a>range</a>'s [=tree/root=], [=Range/set the start=]
-            <var>newRange</var>'s [=range/start=] and [=range/end=] to
-            <var>newFocus</var>.
+            <li>If <var>node</var>'s [=tree/root=] is not the same as
+            [=this=]'s <a>range</a>'s [=tree/root=], <a>reset the range</a> with
+            <var>newFocus</var> and <var>newFocus</var>.
             </li>
             <li>Otherwise, if <var>oldAnchor</var> is [=boundary point/before=]

> For composed selection range, we determinate the anchor/focus based on the direction.

It is the directionality check that I believe we're still breaking in this PR. Right now, steps 4 and steps 5 might be broken. Imagine the following scenario:

```html
<html>
  <div id=shadowHost>
    <p id=anchor></p> <!-- In the shadow DOM -->
  </div>
  <p id=focus>...</p>
</html>

getSelection().setBaseAndExtent(anchor, focus);
```

Because your **step 4** condition checks both same-root-ness _and_ "before"-ness, we will fail the same-root condition and call "set the composed selection range" with focus and anchor, which I think is out of order. Then, **step 5** will unconditionally check the "before"-ness, which blows up because DOM's "before"-ness asserts that the two endpoints share the same root: https://dom.spec.whatwg.org/#concept-range-bp-position.

Consider the exact opposite scenario:

```html
<html>
  <p id=focus>...</p>
  <div id=shadowHost>
    <p id=anchor>...</p> <!-- In the shadow DOM-->
  </div>
</html>

getSelection().setBaseAndExtent(anchor, focus);
```

This also fails your **step 4** condition of `setBaseAndExtent()`, because they are not same-root. This accidentally results in "set the composed selection range" being called with focus/anchor in the right order this time, but the directionality check in **step 5** still blows up.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/pull/345#discussion_r1989473998
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/pull/345/review/2674913743@github.com>

Received on Tuesday, 11 March 2025 14:52:41 UTC