See the attached test case.
Created attachment 14073 [details] Test case
This bug affects the Web Inspector (at least on trunk).
Corrected the revision range of the regression. The later changes merely made the issue visible in the inspector.
This bug is a regression from Safari 2.0.4 since it also affects <button>. The regression was caused by <http://trac.webkit.org/projects/webkit/changeset/18819>. The RenderBox::computeAbsoluteRepaintRect() logic for the hasControlClip() case is very strange - it doesn't look at the container o at all. I think it should intersect with o's controlClipRect(). However, in the case of this bug, the controlClipRect() is invalid since the container is in mid-layout (exactly the same problem discussed in the comments for the hasOverflowClip() case).
Created attachment 14122 [details] Just ignore lightweight clip in repaint rect computation I think it's okay for now to just ignore the clip. Typically the contents don't overflow the control anyway, so this shouldn't cause successive repainting (for popups and listboxes, the contents are completely controlled by the engine).
Comment on attachment 14122 [details] Just ignore lightweight clip in repaint rect computation r=me; seems OK to ignore the clipping when repainting
Landed in r21002.
Please file a followup bug to track the FIXME added to the code.
(In reply to comment #8) > Please file a followup bug to track the FIXME added to the code. > Bug 13443.