Bug 11974 – REGRESSION: Caret drawn over input when smaller than font size on initial focus

• Component: Forms
• Status: RESOLVED FIXED

[Matt Lilek]

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.

[Mark Rowe (bdash)]

<rdar://problem/4960258>

[Antti Koivisto]

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.

[Maciej Stachowiak]

Comment on attachment 13163 [details]
Set controlClip for non-search text controls

r=me

[Sam Weinig]

Landed in r19626!

[Antti Koivisto]

Turns out fix is not good. It causes problems with some text fields (google!) so reopening and reverting the patch.

[Sam Weinig]

Comment on attachment 13163 [details]
Set controlClip for non-search text controls

Removing review flag so that this does not get landed accidentally.

[Antti Koivisto]

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.

[Dave Hyatt]

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.

[Antti Koivisto]

Created attachment 13230 [details]
do a more generic test to avoid double paint

[Dave Hyatt]

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!

[Dave Hyatt]

Disregard my comment.  I'm wrong about that ordering being better.

[Antti Koivisto]

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.