We fail the test case in the given URL. It looks like we let a background element bleed through somehow. This bug is probably a dupe but I'm not sure what the underlying issue is.
Maybe the negative value in border radius should cause us to ignore that rule, and we're not?
There is no explicit mention of non-negativity of border radii in the spec: http://www.w3.org/TR/css3-background/#the-border-radius The interpretation held in Gecko and IE of strict non-negativity seems reasonable given the lack of description of how negative radii ought to be rendered. A quick test of making this change in the parser results in a pass. I'll upload a patch shortly. There also seems to be a regression on part of this test case since this bug was filed - I'll look into that after resolving the issue at hand.
Created attachment 94032 [details] Patch
Comment on attachment 94032 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=94032&action=review > LayoutTests/fast/css/border-radius-non-negative.html:15 > + border-radius: 30px -150px 30px 30px; Would be nice to also test a combination of illegal border-top-left-radius with legal border-top-right-radius (for example).
Created attachment 94041 [details] Patch
Comment on attachment 94041 [details] Patch Clearing flags on attachment: 94041 Committed r86830: <http://trac.webkit.org/changeset/86830>
All reviewed patches have been landed. Closing bug.