Summary: | REGRESSION: Caret drawn over input when smaller than font size on initial focus | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Matt Lilek <dev+webkit> | ||||||||
Component: | Forms | Assignee: | Antti Koivisto <koivisto> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | koivisto, KwhiteRight | ||||||||
Priority: | P1 | Keywords: | HasReduction, InRadar, Regression | ||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
URL: | data:text/html,<input type="text" style="height: 10px"> | ||||||||||
Attachments: |
|
Description
Matt Lilek
2006-12-25 23:02:46 PST
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
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. 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. |