When -moz-border-radius is applied to <td> elements, the table cell borders are curved appropriately. However, reftest exposes minute differences in curvature compared with same-size SVG rectangles. Test files, and reftest analyzer screenshot attached. The CSS3 spec does not define how border-radius should be handled by internal table elements (except when border-collapse is set), and in any case the difference here is not visually apparent, so I'm not sure whether we care about this or not.

Jonathan: please cc: me explicitly on future border-radius bugs. I would bet that these minute differences of curvature that you observe are down to the table cells not being precisely the size that the SVG test case expects: a difference of less than a pixel, which gets rounded away when deciding where the sides will actually be drawn, but still affects curve positioning. I'm egregiously unfamiliar with what can and cannot be done with table rendering -- is it possible for you to constrain the box size of the table cells themselves, rather than having the table layout code infer this from the size of the table and the requested inter-cell padding?

(In reply to comment #3) > is it possible for you to constrain the box size of the > table cells themselves, rather than having the table layout code infer this > from the size of the table and the requested inter-cell padding? Yes, but the same problem occurs. I'm updating the testcase (HTML) with the table cells defined the same size as the SVG rectangles; same reftest difference. (Parenthetically, I had to specify the table cells as 25x35 to get 35x35 cells for some reason I can't explain.)

I'd like to see a cairo trace and/or the result of sticking a printf() of all arguments into gfxContext::RoundedRectangle(). That would also be interesting for bug 459945.

I'm attaching the reftest log for this single reftest, after adding printf's to dump all arguments to gfxContent::RoundedRectangle(). The code I added is: void gfxContext::RoundedRectangle(const gfxRect& rect, const gfxCornerSizes& corners, PRBool draw_clockwise) { printf("gfxContext::RoundedRectangle() called with args:\n"); printf(" rect.pos.x=%f\n", rect.pos.x); printf(" rect.pos.y=%f\n", rect.pos.y); printf(" rect.size.height=%f\n", rect.size.height); printf(" rect.size.width=%f\n", rect.size.width); printf(" corners[gfxCorner::TOP_LEFT]=%f,%f\n", corners[gfxCorner::TOP_LEFT].width, corners[gfxCorner::TOP_LEFT].height); printf(" corners[gfxCorner::TOP_RIGHT]=%f,%f\n", corners[gfxCorner::TOP_RIGHT].width, corners[gfxCorner::TOP_RIGHT].height); printf(" corners[gfxCorner::BOTTOM_LEFT]=%f,%f\n", corners[gfxCorner::BOTTOM_LEFT].width, corners[gfxCorner::BOTTOM_LEFT].height); printf(" corners[gfxCorner::BOTTOM_RIGHT]=%f,%f\n", corners[gfxCorner::BOTTOM_RIGHT].width, corners[gfxCorner::BOTTOM_RIGHT].height); ... Looking at the log, all numbers passed to this function are nice and round, no half-pixel numbers which might cause rounding differences.

I was able to tweak the test case so that it passes.

I made some adjustments to both files to eliminate "noise" differences: - strip the HTML wrapper and 6-pixel horizontal+vertical offsets from the SVG reference - specify *{margin: 0; padding:0} in the HTML - remove all text content from the table (i.e. just have <td></td>) - don't position the table but the real change was to not specify any border at all on the TDs. border:none + -moz-border-radius:4px + background:black causes the background color to be drawn clipped to a rounded rectangle, which is functionally equivalent to what SVG does for a single <rect> element. Based on the traces, I think the problem was that the original HTML was *not* functionally equivalent to a single SVG <rect>; the black border and the black background were drawn as two separate entities, and I think that caused the corners to get drawn a different number of times in the HTML than in the SVG. Drawing the same curved fill over itself repeatedly in Cairo is not the same thing as drawing it once. So I'm inclined to say this is not a bug, but I'm not going to close it either.

At first it may seem that drawing two times the corners is wrong, but in fact I think that it's a case of the -moz-background-clip property set to clip at "outer" border edge, instead of "padding", ie "inner edge" of border. That way, the background is drawn once with the border *included*, and then the border is painted on top of that. You should verify what I say, but I think it is really not a bug.