Bug 7319 – Can't see caret at the end of a contenteditable div with overflow:hidden

• Component: HTML Editing
• Status: RESOLVED FIXED

[Adele Peterson]

See test case.  In the new text fields, the caret stops blinking when you arrow over to the right edge.

[Adele Peterson]

Created attachment 6555 [details]
test case

[Adele Peterson]

Created attachment 6559 [details]
patch

I'm not sure this is the right approach for the long term, but it solves this specific problem.  Maybe we want a render class for any renderer that has an anonymous DOM tree.

[David Harrison]

Agreed that this patch does not seem right.  Reason is that the loop you're changing is trying to skip what I'd call "intermediate" nodes, but I would not a call a text field intermediate.

Please elaborate on what is going wrong to cause this bug (apparently something to do with anon DOM?), then I'll try to help with longer term solution.  Thanks.

[Adele Peterson]

When the caret is at the end, and RenderBlock::paintCaret is called for the RenderTextField, the containing block for the text node is its parent div (which is anonymous), and not the RenderTextField, which is preventing paintCaret from actually painting.

At other caret positions, paintCaret isn't called for the RenderTextField-- only for the div, so the containingBlock matches the caller.  So maybe we should never be getting to the point where the RenderTextField is trying to draw the caret?

[Adele Peterson]

<rdar://problem/4463504> caret stops blinking when it reaches the end of the new text field (7319)

[Adele Peterson]

justin and i discussed the possibility that the div just needed more padding, but after experimenting, that doesn't seem to have any effect.

I was also able to reproduce the problem with a normal div.  I'll attach the test case.

[Adele Peterson]

Created attachment 6900 [details]
test case w/ editable div

[Adele Peterson]

One explanation is that the div's overflow layer is not large enough for the caret at the end.

RenderLayer::computeScrollDimensions uses the rightmostPosition to compute the scrollWidth.  rightmostPosition will compute a position based on the text nodes in the block.  If we add code to account for the possibility of a cursor, then the rightmostPosition would increase by 1 in this case.

Something like this in RenderBlock::rightmostPosition...

// If this node is a root editable element, then the rightmostPosition should account for a caret at the end.
if (node()->isContentEditable() && node() == node()->rootEditableElement())
    right += 1;

This does the trick, but I'm not sure its the right thing to do.

[Adele Peterson]

Created attachment 6921 [details]
patch

I don't think this addresses the rtl case- but my testing showed that there are other serious problems with the caret displaying correctly for rtl editable areas, which makes it difficult to test this specific case.

[Dave Hyatt]

Comment on attachment 6921 [details]
patch

You should add style()->direction() == LTR as well.

r=me