Selection API: Further improvements to VisibleSelection, FrameSelection, and DOMSelection to preserve anchor and focus
Created attachment 409222 [details] Patch
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.
(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.
(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.
Created attachment 409240 [details] Patch for landing
Committed r267329: <https://trac.webkit.org/changeset/267329>
<rdar://problem/69318406>