User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090119 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090119 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) When a box-shadow is used on an element with corners rounded via a border-radius, the anti-aliasing to smooth the rounded corners blends with the background-color for the parent element, not the effective background-color that is produced by the box-shadow. Reproducible: Always Steps to Reproduce: Visit attached test case. Actual Results: Red curves are seen at the corners. Expected Results: No red should be visible.
Created attachment 357760 [details] Simplified test case Simplified test case showing the visible artifacts.
Keywords: css-moz, testcase
Version: unspecified → 3.1 Branch
works for me
(In reply to comment #2) > works for me Can you please include your build information.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 3.1 Branch → 1.9.1 Branch
I think this is probably a duplicate of a bug requesting that we use supersampling for anti-aliasing, if there is one. In our current architecture, things don't antialias "with" other things; the edge is simply partially opaque and drawn over whatever else was drawn there before, independent of parts of the pixel covered.
(In reply to comment #4) > things don't antialias "with" other things; the edge is simply partially opaque This seems like the best solution anyway. Could this be solved then, by drawing the box-shadow under the entire source box when it contains partially opaque pixels/regions? Or at least drawing them under any partially opaque pixels; possibly better, not sure which is more expensive: drawing what won't be seen or figuring out which pixels or regions are partially opaque? It could still be optimized for the (probably? hopefully?) typical case where the source box is completely opaque.
(In reply to comment #5) > Could this be solved then, by drawing the box-shadow under the entire source This would be incorrect. I just re-read the spec (http://www.w3.org/TR/css3-background/#the-box-shadow) and it says: "The shadow is drawn outside the border edge only" so my suggestion above wouldn't apply. I still think that it should draw the shadow where the edge has partially transparent pixels as in the test case.
Created attachment 398732 [details] testcase without shadow I've seen the same problem recently, but without box-shadow. Border-radius should not use transparency for anti-aliasing because the backgrounds or shadows under the box are making it with unexpected mixed color, and sometimes is very ugly.
Severity: trivial → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: css-moz → css3
Summary: -moz-border-radius with -moz-box-shadow anti-aliases with background-color instead of shadow color → -moz-border-radius should not use transparency for anti-aliasing
Border-radius is just filling the space between two rounded rectangles, and I don't think Cairo gives us any control over whether or not its curved-edge antialiasing uses transparency. Looking at your test cases, I think this is the same as bug 466572.
Also bug 527695 describes the same issue. So two of them should be marked as duplicates of the other one. 527695 was the first one I found searching for the problem seen, so I'd say, this issue and 466572 should be marked as duplicates of 527695 even when they were entered before.
Comment on attachment 357760 [details] Simplified test case The "Simplified test case" file no longer shows the issue due to using the -moz- prefix on border-radius and box-shadow. The file should be changed as follows: >ï»¿<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> ><html xmlns="http://www.w3.org/1999/xhtml" > <!DOCTYPE html> <html> > -moz-border-radius: 1em; > -moz-box-shadow: 0 0 0 0.5em Green; -moz-border-radius: 1em; -moz-box-shadow: 0 0 0 0.5em Green; --- There are also mixed tabs/spaces. I wasn't able to submit a file and mark the old one as obsolete, or I would have done that instead.
Created attachment 8574849 [details] TestCase.htm Updated per Comment 10. Thanks for noticing.
Attachment #357760 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.