When an input is smaller than the font size, the caret will be drawn over the focus ring until text is entered into it, after that the caret is properly clipped.
<rdar://problem/4960258>
Created attachment 13163 [details] Set controlClip for non-search text controls Set controlClip but don't enable it for search fields (which have m_innerBlock) since icons would get clipped away. Search fields have minimum height anyway.
Comment on attachment 13163 [details] Set controlClip for non-search text controls r=me
Landed in r19626!
Turns out fix is not good. It causes problems with some text fields (google!) so reopening and reverting the patch.
Comment on attachment 13163 [details] Set controlClip for non-search text controls Removing review flag so that this does not get landed accidentally.
Created attachment 13229 [details] if caret is on a layer make sure it is painted by that layer Actual problem is that the caret is painted twice, once by the associated renderer and another time by renderer's containing block. Painting done by the containing block won't respect clipping established by the renderer. I'm not actually sure why it is ever necessary to paint caret in both the associated renderer and the containing block. The patch just fixes a case where this double painting actually causes problems.
Comment on attachment 13229 [details] if caret is on a layer make sure it is painted by that layer Seems like we should just let the block that the caret is in always paint the renderer. I do not understand how a double painting situation is occurring and think we should stop that rather than adding a layer check that should not be necessary.
Created attachment 13230 [details] do a more generic test to avoid double paint
Comment on attachment 13230 [details] do a more generic test to avoid double paint I'd probably ask isBlockFlow first (since it's quicker than containingBlock()). r=me!
Disregard my comment. I'm wrong about that ordering being better.
r19706
The fix caused a regression where sometimes the caret isn't painted at all. See for example <http://build.webkit.org/results/post-commit-pixel-powerpc-mac-os-x/3675/editing/pasteboard/4641033-diffs.html>. You can open the test in Safari and see that when the caret is at the very end of the contenteditable div, after the select, it does not paint.