[webkit-reviews] review requested: [Bug 6831] contentEditable outline darkens as caret moves : [Attachment 6366] workaround patch

bugzilla-request-daemon at opendarwin.org bugzilla-request-daemon at opendarwin.org
Thu Feb 9 05:19:13 PST 2006

Graham Dennis <Graham.Dennis at gmail.com> has asked Justin Garcia
<justin.garcia at apple.com> for review:
Bug 6831: contentEditable outline darkens as caret moves

Attachment 6366: workaround patch

------- Additional Comments from Graham Dennis <Graham.Dennis at gmail.com>
The problem appears to be caused by a limitation in WebClipView restricting the
focus ring clip to be a single rectangle (and not a graphical union of
With focus ring redraws, what normally happens seems to be that the complete
focus ring is drawn by the WebHTMLView, but the WebClipView restricts this to
the repaint rectangle. However, in cases where the repaint region is a number
of non-nested rectangles (e.g. when a caret needs to be cleared at one location
and redrawn at another location), the WebClipView restricts focus ring
redrawing to the minimum rectangle enclosing all rectangles that are to be
redrawn. This will include some space where we do not want the focus ring
redrawn as it hasn't been cleared there.
For the specific case of the caret, the repaint rectangle has been extended 1px
in all directions around the caret (apparently to avoid ensure no artifacts are
left behind), which now extends 1px into the focus ring (both above and below).
When the caret needs to be cleared and redrawn elsewhere at the same time (when
the caret is moved while it is still visible) this causes the clip rectangle
used by WebClipView to be the minimum enclosing rectangle which now includes
1px of the focus ring above and below the text, thus causing it to be redrawn.

The perfect fix for this would be to make WebClipView support multiple clip
rectangles (getting these clip rectangles from the repaint rectangles of the
WebHTMLView), but that would require the - (NSRect) _focusRingVisibleRect
method to support multiple rectangles, but this is called by
WKSetFocusRingStyle which is a private function in libWebKitSystemInterface.a

As a workaround to the main source of the problem, I have attached a patch
which removes the 1px of slop around the caret. I haven't seen any artefacts
caused by this change.

More information about the webkit-reviews mailing list