If there is no line wrapping, a caret can leave its containing block but it shouldn't leave its root line box. Otherwise I believe it can be clipped by the containing blocks outline. Test case forthcoming. <rdar://problem/6800956>
Created attachment 29593 [details] patch
Comment on attachment 29593 [details] patch You should add a reference to the test to the WebCore ChangeLog. I don't think this covers all cases. Not all textAlign() values that are not LEFT should behave the same, and I think in most cases (maybe even for LEFT and RIGHT) the behavior also needs to take style()->direction() into account, because that's how we decide on which side of the block the overflow goes. See the logic in RenderBlock::computeHorizontalPositionsForLine().
(In reply to comment #2) > Not all textAlign() values that are not LEFT should behave the same oops! will fix...
Created attachment 29597 [details] patch patch with new test case to cover the case that dan mentioned, where the text-align is right but the direction is LTR. In that case we spill over to the right off the block like we do in other direction:LTR cases.
Comment on attachment 29597 [details] patch r=me There's a problem with this and earlier caret painting patches in that the difference between correct and incorrect behavior in the pixel test is below our detection threshold. I am not sure what to do about it (maybe use the Mac SPI that's exposed via DRT for getting caret rects?), but addressing that is not part of this bug.
Maybe caretWidth should be settable at runtime via a CSS property, or DRT API, and we can make it really fat?
I don't think we want a CSS property for it, but maybe a WebView SPI.
I'll correct the test description to say that the problem is that the caret paints over the focus halo a bit (rather than getting clipped).
http://trac.webkit.org/changeset/42634
and http://trac.webkit.org/changeset/42635