Bug 53787 – REGRESSION: Caret is rendered at wrong location when editable region ends with a non-editable region

• Status: NEW
• Component: HTML Editing

[Ryosuke Niwa]

In the following markup,
<div contenteditable>text text<span contenteditable="false">foo</span></div>

Clicking a position right after foo results in the caret rendered at the right upper corner instead of at the end of foo.

[Ryosuke Niwa]

http://crbug.com/71598

[Levi Weintraub]

This unfortunate bug is non-trivial to solve. Editing creates canonical positions that are eventually sent to Render____::localCaretRect to have the rect determined. In certain cases like this, the canonical position editing would *normally* create, ["foo", 3], doesn't work (in this case because it's in non-editable content). There are 2 problems with this:

1) RenderBlock uses RenderBox to determine the caret rect, but for RenderBox, any offset > 0 equates to drawing the caret after the content, even if it's an offset between children.
2) A RenderBlock and offset isn't enough information to determine the correct position for the caret. [DIV, 2] in this case could be interpreted to the position after "foo" or the position after the DIV! I think localCaretRect needs to take a type (offset into children, or position before/after renderer e.g. Position::AnchorType).

[Garry Boyer]

Created attachment 82009 [details]
This demonstrates the issue and a couple other cursoring bugs in this use case, but only one of them is a regression (the one tracked on this bug).

[Garry Boyer]

Also wanted to emphasize that this issue didn't exist earlier, it was a regression from Chrome 8 to Chrome 9.  Maybe there were some hacks in earlier versions that fixed this.

[Levi Weintraub]

The bug where a line break is inserted when backspacing the whitespace following a button is similarly related to legacy positions. DeleteSelectionCommand uses mergeParagraph to handle selections that span paragraph boundaries, and because it upstreams the resulting position after the deletion into [button, 1], the code falsely believes the position to be inside the inline-block element and inserts a placeholder.

The "right" fix for this would be to make Position::upstream() return a position at [button, PositionIsAfterAnchor] and have DeleteSelectionCommand then correctly handle positions after Inline-Block flow elements (where positions before/after treat them like inline nodes and positions inside them like blocks).

[Piotrek Koszuliński (Reinmar)]

The issue was also reported on CKEditor's bug tracker: http://dev.ckeditor.com/ticket/11923