Bug 50481 – Caret is incorrectly painted if the final position follows non-editable content.

• Status: NEW
• Component: HTML Editing

[Levi Weintraub]

When the selection is a caret at the final position of an editable div immediately following non-editable content, the caret is painted at the right edge (or left edge in RTL) of the div instead of after the non-editable content. 

Consider this DOM:

DIV contenteditable=true
  SPAN contenteditable=false
     text "Foo"

Because the positions [SPAN, 1] or [text, 3] are not candidates, we end up with [DIV, 1], which is painted incorrectly despite being equivalent.

[Levi Weintraub]

Created attachment 75537 [details]
Test case

[Levi Weintraub]

The bug actually appears to be in Position::getInlineBoxAndOffset. The check here: http://trac.webkit.org/browser/trunk/WebCore/dom/Position.cpp?annotate=blame&rev=72777#L1038

which is intended to prevent infinite recursion also has the side effect of not actually checking the upstream position when *this is the downstream position. Changing the line to

if (equivalent == *this || (canHaveChildrenForEditing(equivalent.node()) && equivalent.node()->renderer()->isBlockFlow()
    && hasRenderedNonAnonymousDescendantsWithHeight(equivalent.node()->renderer())))

solves the problem but isn't pretty.

[Ahmad Saleem]

I am able to reproduce this bug in Safari 16.1 using attached test case and placing caret after "Foo" will show Caret at end of content editable like it is RTL, while Firefox Nightly 108 does not show any caret at all. Chrome do show caret at right position.

Changing status to "New". Thanks!