User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5 (.NET CLR 3.5.30729) The border radius implementation seems to have changed in Firefox 3.5. The edges of the header at the demo URL no longer touch the background, presumably because the border radius is fairly large. I don't know if this is intended, but it looks weird to me. Reproducible: Always Still happens with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre, presumably an issue on all OSes.

Probably occurs on any element, and border-color seems related.

Regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=89847884d010&tochange=1a4e256b6894

This is almost certainly fallout from bug 456219, but I'm hesitant to call it a regression; I would say the current rendering is closer to the specified behavior than the old rendering, though clearly worse in terms of appearance. The test case I'm attaching has three columns (if your window is wide enough): on the left are the same pair of constructs that appear in attachment 384841 [details], only revised to eliminate dependence on font size. The middle column shows what happens if you make the left and right borders be a very thin red line instead of 'none', and the right column has SVG renderings of what I think we *should* be drawing. What's going on is, because the borders at top and bottom are solid and the borders at left and right are 'none', we clip background painting to the padding box. The padding box is bent inward by the border-radius specification, on the theory that there *will be* a border drawn on all four sides. But the border actually drawn at left and right is 'none' so we get these white gaps. What *should* be happening at upper left, as I read the spec, is that the blue paint should extend into the white region, as shown at the far right. This is just the logical extrapolation of the behavior in the middle top. The middle top shows a second bug in this area: there should be no white gaps in that case either. We are not choosing the boundary between border sides correctly when there is no or a very thin border on one side and a very thick border on the other. The bottom row shows a third bug: the default black border-color should not behave differently from an explicitly specified border-color. I'm putting this on my list, but before I start messing with the code, I would appreciate a second opinion on the appropriate behavior here.

gah, either I picked the wrong file or bugzilla decided to eat my embedded SVG.

The SVG seems pretty close to what I'd expect, except for the issue that the border-box of the boxes aren't actually rectangles, so we should be hitting the radius-reduction case and thus getting some straight segments along the top and bottom. I think the SVG is showing what I'd expect if the testcase used elliptical border-radii (moz-border-radius: 72pt / 61pt, I think).

(In reply to comment #6) > The SVG seems pretty close to what I'd expect, except for the issue that the > border-box of the boxes aren't actually rectangles, so we should be hitting the > radius-reduction case and thus getting some straight segments along the top and > bottom. Yeah, I forgot about radius reduction when I did the SVG version.

Here's another test case, with a related SVG, demonstrating how I think this case should be rendered, in a case where border-radii reduction doesn't need to take place. If people agree, this could be reftested.

I would expect border-style: none; to be treated the same as border-style: solid; border-width: 0; No? Your renderings on the right in the SVG look close to correct to me.

(In reply to comment #10) > I would expect border-style: none; to be treated the same as border-style: > solid; border-width: 0; No? Your renderings on the right in the SVG look close > to correct to me. That makes sense to me. Could we maybe get an example of this case added to css3-background?

Sure! Throw me the CSS you want and I'll get a reference rendering added. :)

I no longer work for Mozilla, I am deassigning myself from bugs I have no intention of working on as a volunteer.

A common aspect to this testcase is that the joins are broken when they're a transition to border-*-style: none, but they work fine with border-*-width: 0. That, plus attachment 385837 [details] seems to show (as Zack pointed out in comment 4) a bug in our ability to (as an optimization) adjust the background fill area between border-box and padding box; I'm guessing we're not checking for the initial (use-text-color) border-color correctly.

An additional test that shows we basically implement all the functionality we need; we just need to invoke it correctly. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Adiv%20%7B%20display%3A%20inline-block%3B%20width%3A%20120px%3B%20height%3A%20120px%3B%20%7D%0A.div0%20%7B%20height%3A%20120px%3Bwidth%3A%20120px%3B%20border%3A%2010px%20solid%20green%3B%20border-radius%3A%2060px%3B%20background%3A%20yellow%3B%20border-width%3A%2030px%200%2030px%200%3B%20margin%3A%200%3B%20border-left-style%3A%20none%3B%20%7D%0A.div0%23a%20%7B%20border-right-color%3A%20orange%3B%20%7D%0A.div0%23b%20%7B%20border-right-color%3A%20orange%3B%20border-right-width%3A%201px%3B%20%7D%0A%0A.div1%20%7B%0A%20%20%20%20%20%20border-top%3A%2030px%20solid%20blue%3B%20%0A%20%20%20%20%20%20border-bottom%3A%2030px%20solid%20blue%3B%0A%20%20%20%20%20%20border-radius%3A%2060px%3B%0A%20%20%20%20%20%20background%3A%20red%3B%0A%7D%0A%0A.div2%20%7B%0A%20%20%20%20%20%20border-top%3A%2030px%20solid%3B%20%0A%20%20%20%20%20%20border-bottom%3A%2030px%20solid%20blue%3B%0A%20%20%20%20%20%20border-radius%3A%2060px%3B%0A%20%20%20%20%20%20background%3A%20yellow%3B%0A%7D%0A%0A%0A%3C%2Fstyle%3E%0A%20%20%3Cdiv%20class%3D%22div0%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20class%3D%22div0%22%20id%3D%22a%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20class%3D%22div0%22%20id%3D%22b%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20class%3D%22div1%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20class%3D%22div2%22%3E%3C%2Fdiv%3E

I think this should block, given that we're turning on border-radius.

(In reply to comment #18) > That, plus attachment 385837 [details] seems to show (as Zack pointed out in comment 4) a > bug in our ability to (as an optimization) adjust the background fill area > between border-box and padding box; I'm guessing we're not checking for the > initial (use-text-color) border-color correctly. And, for the record, IsOpaqueBorderEdge has the comment: // We don't know the foreground color here, so if it's being used // we must assume it might be transparent. if (isForeground) return PR_FALSE;

http://hg.mozilla.org/mozilla-central/rev/bb8146cbac63 ... but I really need to get a test in as well.

Testcase #three in attachment 384912 [details] still isn't right, though...

Reopening for that; I'm suspicious of the calculation of k in MaybeMoveToMidPoint.

... and add comments explaining what this function *actually* does.

Comment on attachment 488952 [details] [diff] [review] fix the issue in comment 24 +// Given three points, p0, p1, and midPoint, move p1 further in to the +// rectangle What rectangle?

I added reftests for the two issues fixed by recent patches in this bug: http://hg.mozilla.org/mozilla-central/rev/b80c7aadda83 (one for each patch; the first based on tests above). I filed bug 613266 on the remaining issue in attachment 488954 [details]. Marking this bug as fixed.

The second test had a one-pixel error on Windows opt builds only: http://hg.mozilla.org/mozilla-central/rev/1d85ad54b112 (I ran try server on three platforms, debug only)

(In reply to comment #31) > The second test had a one-pixel error on Windows opt builds only: > http://hg.mozilla.org/mozilla-central/rev/1d85ad54b112 > (I ran try server on three platforms, debug only) Therefore I marked it as random on Windows: http://hg.mozilla.org/mozilla-central/rev/1d85ad54b112