See test case. In the new text fields, the caret stops blinking when you arrow over to the right edge.
Created attachment 6555 [details]
Created attachment 6559 [details]
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.
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.
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?
<rdar://problem/4463504> caret stops blinking when it reaches the end of the new text field (7319)
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.
Created attachment 6900 [details]
test case w/ editable div
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.
Created attachment 6921 [details]
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.
Comment on attachment 6921 [details]
You should add style()->direction() == LTR as well.