In bug 407093 comment 42, I noted that Aqua focus rings on buttons are still being clipped. Then: --- Comment #44 Colin Barrett 2007-12-22 04:26:35 PST --- (In reply to comment #42) > I'm noticing that we're still clipping the Aqua focus rings on buttons with > "fix v1.7"; is that something that should be fixed here, or a new bug? We may need to increase the size of the rendered rect after all. I had to do this in my patch for dropdowns. Increase the size of the buffer, shift buffer's CTM by x+4, y-4, draw, shift the context's CTM by x-4, y+4, draw the image into the buffer. The odd signs are because when you are drawing your buffer image into cgContext you have flipped the origin. It can get a little confusing, so have a whiteboard at the ready. --- Comment #45 Josh Aas 2007-12-23 11:22:38 PST --- Yeah, I know this doesn't solve our problems with focus rings. I'd rather do that in a separate bug. There is more than just clipping that needs to be figured out. landed on trunk --- You can use any testcase like https://bugzilla.mozilla.org/attachment.cgi?id=99911&action=view https://bugzilla.mozilla.org/attachment.cgi?id=261916&action=view to check this out. On Hyatt's form controls (the first one), I also notice the bottom and right sides of the ring aren't erased on the square multiline <button> when you tab away from it. Actually, if you increase font sizes so that the round Aqua buttons become square ones, they almost all show the incomplete erasure, too, so it seems to be related to square Aqua buttons.

Comment on attachment 295845 [details] [diff] [review] fix v1.0 It might be clearer if you put the definitions of finalCopyRect, initialBufferSize, and bufferRenderRect nearer to where they actually get used, but this way is alright. Perhaps you could leave the clipRect: call in in but inflate the clipping rect if we're drawing a focus ring?

If some control is drawing outside of the clip rect we would set and it doesn't cause problems that is probably OK. If it is drawing outside of the rect and it causes reftests to fail, I actually do want to know about that. My position has sort of changed after looking at this overflow stuff.

Comment on attachment 295845 [details] [diff] [review] fix v1.0 It would be nice if the magic number 4 was shared with nsNativeThemeCocoa::GetWidgetOverflow; these have to stay in sync.

patch I actually landed, address roc's comment and move generic functions further up in the file

landed on trunk

This is a little bit better, but there's still a lot of clipping and incomplete erasure going on. Sorry, I've just now gotten to checking on some of these old bug. I'll attach screenshots from tonight's Minefield; please compare to Safari 3.

See, for instance, the bottom part of the ring is much smaller than the top/sides. This is from the reduced-412berea testcase: https://bugzilla.mozilla.org/attachment.cgi?id=261916&action=view

From hyatt's https://bugzilla.mozilla.org/attachment.cgi?id=99911&action=view "Normal" shows bad erasure, "Reset" has its botton and right side clipped, and the <button> also shows bad erasure.

Here, the bottom is clearly clipped; the right side might also be clipped a little.

Note that the ring thickness is completely inconsistent (which I think might be "normal"), but the bottom and right side look to have a flat cut-off to the ring (and thinner than the others).

Please file a new bug for each individual control type that has clipping problems. That is how we need to track these issues at this point.