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.
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).
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).
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.
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).
The issue was also reported on CKEditor's bug tracker: http://dev.ckeditor.com/ticket/11923