Bug 216739 – Selection API: Further improvements to VisibleSelection, FrameSelection, and DOMSelection to preserve anchor and focus

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Darin Adler]

Selection API: Further improvements to VisibleSelection, FrameSelection, and DOMSelection to preserve anchor and focus

[Darin Adler]

Created attachment 409222 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 409222 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=409222&action=review

Looks like editing/execCommand/insert-list-nested-with-orphaned.html is failing legitimately.

> Source/WebCore/editing/VisibleSelection.cpp:234
> +    m_baseIsFirst = m_base <= m_extent;

We may need to take care of the case when m_base / m_extent turns until null even though m_anchor / m_focus aren't null.

[Darin Adler]

(In reply to Ryosuke Niwa from comment #2)
> Looks like editing/execCommand/insert-list-nested-with-orphaned.html is
> failing legitimately.

I’ve been studying the test, and I think the change in behavior is a small progression. The test does InsertOrderedList on a selection, and the new behavior is that after insertion the whole thing is still selected. The old behavior was that the caret was at the beginning of the line of the last list item. I don’t see this behavior, changing a selection into a caret, as intentional in the implementation and it’s not done in any normal case.

What I don’t understand yet is why the selection anchor and focus are not visible in the dump. Trying to figure that out now.

[Darin Adler]

(In reply to Darin Adler from comment #3)
> What I don’t understand yet is why the selection anchor and focus are not
> visible in the dump. Trying to figure that out now.

Looks like dump-as-markup.js only dumps an anchor, focus, or caret indicator when they happen to have a text node as the container node, and misses them when the node is a non-text node. This seems like something we should fix by enhancing dump-as-markup.js, but further explains what is happening here.

The caret is not going to move itself into a text node any more, even if it is a caret! It was doing that before as non-standard behavior. We set the selection to the children of a node, so that node is going to be the container specified in the selection endpoints, no reason that they would move themselves to be in a text node.

[Darin Adler]

Created attachment 409240 [details]
Patch for landing

[Darin Adler]

Committed r267329: <https://trac.webkit.org/changeset/267329>

[Radar WebKit Bug Importer]

<rdar://problem/69318406>