Bug 53787 - REGRESSION: Caret is rendered at wrong location when editable region ends with a non-editable region
Summary: REGRESSION: Caret is rendered at wrong location when editable region ends wit...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-04 10:20 PST by Ryosuke Niwa
Modified: 2014-05-09 00:54 PDT (History)
6 users (show)

See Also:


Attachments
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). (2.49 KB, text/html)
2011-02-10 11:03 PST, Garry Boyer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-02-04 10:20:00 PST
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.
Comment 1 Ryosuke Niwa 2011-02-04 10:20:12 PST
http://crbug.com/71598
Comment 2 Levi Weintraub 2011-02-04 11:54:03 PST
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).
Comment 3 Garry Boyer 2011-02-10 11:03:09 PST
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).
Comment 4 Garry Boyer 2011-02-10 11:04:08 PST
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.
Comment 5 Levi Weintraub 2011-02-15 16:56:39 PST
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).
Comment 6 Piotrek Koszuliński (Reinmar) 2014-05-09 00:54:03 PDT
The issue was also reported on CKEditor's bug tracker: http://dev.ckeditor.com/ticket/11923