Last Comment Bug 431176 - (border-radius) Tracking bug for remaining issues with CSS3 border-radius
(border-radius)
: Tracking bug for remaining issues with CSS3 border-radius
Status: NEW
: meta
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P2 normal with 45 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 309905 395674 (view as bug list)
Depends on: 315209 318914 438911 455668 466572 474386 475190 483696 500804 523041 664154 697645 760358 382721 383030 424423 427266 450652 451134 458131 459144 459945 471643 485501 500141 500734 527695 537433 538383 593717 613905 652650 803947 901336 947833 1218788
Blocks: css3-background
  Show dependency treegraph
 
Reported: 2008-04-28 09:54 PDT by Gábor Stefanik
Modified: 2016-06-29 02:10 PDT (History)
64 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposal for transition between borders of different thickness (1.44 KB, image/gif)
2008-07-25 05:41 PDT, Bruno Girin
no flags Details

Description Gábor Stefanik 2008-04-28 09:54:55 PDT
CSS3's border radius property is not currently implemented in Mozilla. There is -moz-border-radius, but it's buggy and doesn't match the spec. This bug is about implementing the standard CSS3 border-radius property.

For this, the following are needed:
*Get elliptic corners work,
*Handle the interaction of border-radius and border styles (for example, dotted),
*Fix this: when two different dashed/dotted borders intersect in a radiused corner, the transition is not smooth. I will describe a possible solution in detail later.

Elliptic corners in themselves wouldn't be hard, as long as the borders are not dashed/dotted. However, if they are, then problems arise: where exactly should we put the dots/dashes? A proof-of-concept implementation of this in Javascript is available at http://verens.com/demos/borders/dashed-curve.html.

About the third case: Assume that a 10px blue dotted border intersects with a 15px red dotted one, in a corner with border-radius: 50px 20px. The problem: at which point of the curve should we switch from 10px blue to 15px red? The solution: don't "switch" - do a smooth transition instead. Essentially, going from the first border to the second through the curve, each dot gets a bit bigger than the previous one, and the colors of the dots slowly shift from blue to red. I think that during this color transition, each dot should have a solid color, and not a gradient. (AFAIK the spec doesn't specify this transition case.)
At a dash-dash intersection, the dashes should be drawn as segments of a gradient-colored solid border. 
At a dash-dot intersection, we should decide at a cut-off point where we switch from dashing to dotting. I suggest 50% of the curve. The last dash on the curve should be drawn with a rounded-off end. I case of a color difference, the dashes (including the final, rounded one) should be gradient, while the dots should be solid-colored.
At a solid-dash intersection, the solution is simple: do a continuous color transition, and start dashing @ 50% of the curve.
At a solid-solid intersection, simply draw a gradient transition (if the specs allow it). (http://verens.com/demos/borders/dashed-curve.html gets these color transitions wrong.)
At a double-solid intersection, we should reduce the width of the groove in the double border, until it blends into the solid one. (This might be tricky!)
At a solid-dot intersection, we should start dotting @ 50%. Again, the solid part should be gradient, while the dots should be solid colored (bot each dot different from the previous one). In case of a size difference, make the size of the dots shrink/grow continuously. The ending of the solid part should be rounded off.
At a double-dotted intersection, the switch should again be @ 50%, The double borders should curve together, into a rounded loop. I case of a double-dashed intersection, no curve-up is needed.
Note however that most of these curve-up/transition things are cosmetic issues, and not really needed for spec compliance.
Comment 1 dolphinling 2008-04-28 18:36:59 PDT
Dupe of bug 309905?
Comment 2 Vladimir Vukicevic [:vlad] [:vladv] 2008-04-28 18:44:34 PDT
Yeah, dupe, but Stefanik has a better writeup of issues and ideas here.

Stefanik, if you do decide to tackle this, I would strongly urge you to keep going with the proof-of-concept work first; implement the border rendering in JS using canvas first, as essentially the same drawing operations are available internally.  That's how I did much of the original thebes border code (though I can't find my test harness at the moment to pass it on =/).

However, I don't think that gradients at intersections are the right thing to do; so far there has always been a clean break between border colors at corner joins, and I don't think that border radius should modify that.
Comment 3 David Baron :dbaron: ⌚️UTC-10 2008-04-28 19:23:53 PDT
I believe the CSS WG came up with wording that explains where the color change should be, and how the radius should work when the thicknesses of the two sides are different.  See the editor's draft at http://dev.w3.org/csswg/css3-background/#the-border-radius
Comment 4 Vladimir Vukicevic [:vlad] [:vladv] 2008-06-04 14:52:21 PDT
*** Bug 309905 has been marked as a duplicate of this bug. ***
Comment 5 Damon Sicore (:damons) 2008-06-04 17:22:51 PDT
Adding this to the 1.9.1 triage queue by marking this wanted1.9.1?.  
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-09 19:27:08 PDT
Michael, Vlad says his border patch (bug 424423) handles the rendering side of this, all we need is the style system properties. Perhaps something to keep you busy :-).
Comment 7 Zack Weinberg (:zwol) 2008-07-23 11:35:16 PDT
I can take this if Michael can't.
Comment 8 Michael Ventnor 2008-07-23 17:48:13 PDT
If you have the time for this, that would be nice.
Comment 9 Zack Weinberg (:zwol) 2008-07-24 14:24:56 PDT
The spec seems to have changed quite drastically between http://www.w3.org/TR/css3-background/#the-border-radius and http://dev.w3.org/csswg/css3-background/#the-border-radius especially wrt the shorthand property:

2005 TR:
  border-radius: <length> <length>?
  # equivalent to setting all four border-<corner>-radius props 
  # to the same value
  # for all border-*radius, which is horizontal and which is vertical depends
  # on the writing-mode

2008 ED:
  border-radius: <length>{1,4} [ '/' <length>{1,4} ]?
  # the numbers apply to TL, TR[=TL], BR[=TL], BL[=TR] in that order
  # horizontal before the slash, vertical after
  # no mention of the writing-mode for any of the props

Unless I hear otherwise I'm going to implement the 2008 ED spec.  Also, details of the interaction with border styles at the corners may not be 100% in the first pass.

Also, I'm assuming there's no need to support the -webkit- variant of these properties.
Comment 10 Zack Weinberg (:zwol) 2008-07-24 14:25:28 PDT
grrr, assignment UI still doesn't work the way I think it does.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-24 15:22:59 PDT
(In reply to comment #9)
> Also, I'm assuming there's no need to support the -webkit- variant of these
> properties.

Correct, we never want to implement another vendor's vendor-prefix properties.
Comment 12 Bruno Girin 2008-07-24 15:50:50 PDT
(In reply to comment #9)
> Unless I hear otherwise I'm going to implement the 2008 ED spec.  Also, details
> of the interaction with border styles at the corners may not be 100% in the
> first pass.

I think that's exactly what you should do. In terms of test cases, that's what we should look for:
- identical / different horizontal and vertical radii
- interaction with the border width if different for horizontal and vertical values => different radii for inside and outside the border
- change of style / colour limited to a sharp change at 45˚ or on the diagonal of the rectangle that envelops the rounded corner


> Also, I'm assuming there's no need to support the -webkit- variant of these
> properties.

Absolutely right, keep to the standard, it's complex enough without introducing variants.
Comment 13 Vladimir Vukicevic [:vlad] [:vladv] 2008-07-24 15:54:20 PDT
(In reply to comment #12)
> (In reply to comment #9)
> > Unless I hear otherwise I'm going to implement the 2008 ED spec.  Also, details
> > of the interaction with border styles at the corners may not be 100% in the
> > first pass.
> 
> I think that's exactly what you should do. In terms of test cases, that's what
> we should look for:
> - identical / different horizontal and vertical radii
> - interaction with the border width if different for horizontal and vertical
> values => different radii for inside and outside the border
> - change of style / colour limited to a sharp change at 45˚ or on the diagonal
> of the rectangle that envelops the rounded corner

If all that changes is the parsing, and we get the radii down to CSS border rendering, those three should be working correclty now -- for the last point, currently the change happens along the horizontal from the outer corner to the inner corner of the border region (for any particular corner), so for transitions between a really thick border and a really thin border it won't be 45 degrees.. but it's not clear whether 45 degrees would look better there anyway.
Comment 14 Zack Weinberg (:zwol) 2008-07-24 16:25:32 PDT
The spec actually asks for something a little more subtle:

  The center of color and style transitions between adjoining borders is at the
  point on the curve that is at an angle that is proportional to the ratio of
  the border widths. For example, if the two widths are equal, that point is
  at a 45° angle, and if one is twice the width of the other the point is at 
  a 30° angle. The line demarcating this transition is drawn between the point
  at that angle on the outer curve and the point at that angle on the inner
  curve. The transition must be contained within the segment of the border 
  where the tangent of the inner curve either not defined or is not parallel 
  with the sides of the box. It is not defined what the transition looks like,
  but a gradient is recommended for color transitions.

This is what I'm saying I'm not going to do in the first pass. :)
Comment 15 David Baron :dbaron: ⌚️UTC-10 2008-07-24 18:07:44 PDT
(In reply to comment #9)
> Unless I hear otherwise I'm going to implement the 2008 ED spec.  Also, details
> of the interaction with border styles at the corners may not be 100% in the
> first pass.

Right.  The 2008 spec is a superset of what we already implement; the 2005 spec was not.  It should still be -moz-* prefixed until the spec in question is in CR.
Comment 16 Bruno Girin 2008-07-25 05:41:57 PDT
Created attachment 331294 [details]
Proposal for transition between borders of different thickness

I can't find the exact point in the spec where it specifies this but I seem to remember that a rounded corner between borders of different thickness is meant to be smooth, as illustrated in the attached GIF.
Comment 17 Zack Weinberg (:zwol) 2008-07-25 09:57:27 PDT
Bruno: see figure 8 in http://dev.w3.org/csswg/css3-background/#the-border-radius
(you'll have to scroll down a bit).
Comment 18 Bruno Girin 2008-07-25 12:32:44 PDT
Zack: Ah yes! I knew there was a relevant figure somewhere but Firefox 3.0.1 on my Mac wouldn't show it at first for some reason. I think I'll go write a bug report :-)
Comment 19 Michael Ventnor 2008-07-25 18:26:46 PDT
You probably already know this, but just to make sure it doesn't become an issue, make sure the code that clips the background corners and paints the box-shadow also gets updated.
Comment 20 David Baron :dbaron: ⌚️UTC-10 2008-07-25 18:40:57 PDT
So, really, this should probably be split into a bunch of dependencies:
 1. support for the extended syntax for the shorthand
 2. any graphics changes needed to match the spec (maybe more than one bug)
 3. [once the spec hits CR] renaming -moz-border-radius to border-radius
Comment 21 Gábor Stefanik 2008-07-26 07:31:50 PDT
We might want to call this property -moz-new-border-radius (until it's CR of course), to avoid conflicts with existing uses of -moz-border-radius.
Comment 22 David Baron :dbaron: ⌚️UTC-10 2008-07-26 09:41:02 PDT
(In reply to comment #21)
> We might want to call this property -moz-new-border-radius (until it's CR of
> course), to avoid conflicts with existing uses of -moz-border-radius.

No, we don't.  The syntax is a superset of the current syntax.
Comment 23 Zack Weinberg (:zwol) 2008-08-14 14:19:32 PDT
I'm working on the style system part of this in bug 450652 now.

One thing that's already come up is, the spec has different longhand property names: currently we have -moz-border-radius-topleft etc. where the spec uses border-top-left-radius etc.  I have prepared a large, mechanical patch that converts to -moz-border-top-left-radius etc. but I'm wondering if that's worth doing, given that they'll just have to be renamed *again* when the spec hits CR.

Also, there is existing logic to implement backward compatibility aliases for the CSS property names, but AFAICT not for JS element.style.property notation - those change too, e.g. .MozBorderRadiusTopleft becomes .(Moz)BorderTopLeftRadius.  Is this a problem?
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-14 17:44:40 PDT
(In reply to comment #23)
> One thing that's already come up is, the spec has different longhand property
> names: currently we have -moz-border-radius-topleft etc. where the spec uses
> border-top-left-radius etc.  I have prepared a large, mechanical patch that
> converts to -moz-border-top-left-radius etc. but I'm wondering if that's worth
> doing, given that they'll just have to be renamed *again* when the spec hits
> CR.

I'd slightly prefer to match the CSS3 syntax as closely as possible modulo the vendor prefix, since it makes life easier for authors who are using it (who will probably want to use -webkit-border-top-left-radius etc as well).

> Also, there is existing logic to implement backward compatibility aliases for
> the CSS property names, but AFAICT not for JS element.style.property notation -
> those change too, e.g. .MozBorderRadiusTopleft becomes
> .(Moz)BorderTopLeftRadius.  Is this a problem?

I think it's not a problem.
Comment 25 Zack Weinberg (:zwol) 2008-08-14 19:02:06 PDT
Ok.  I've just attached my patch to that effect to bug 450652.  More tomorrow.
Comment 26 Vladimir Vukicevic [:vlad] [:vladv] 2008-08-14 21:34:28 PDT
Note that I'm all for border-top-left-radius, but I think we may need to keep the -moz-border-radius-topleft as an alias; there are a ton of themes out there that use that spec.  We should get rid of it when the spec goes into CR.
Comment 27 Zack Weinberg (:zwol) 2008-08-15 08:43:04 PDT
(In reply to comment #26)
> Note that I'm all for border-top-left-radius, but I think we may need to keep
> the -moz-border-radius-topleft as an alias

Yup, it's in there (look for gAliases in nsCSSProps.cpp)

Comment 28 Gábor Stefanik 2008-09-21 02:15:24 PDT
By the way, the "2005 TR vs. 2008 ED" question is no longer relevant - implement the new 2008 TR.
Comment 29 Alfred Kayser 2008-10-07 01:23:09 PDT
Adding bug 448193 as there is a regression on border-radius with outset/inset/ridge/groove borders which makes us fail any standards compliancy testing on this combination.
Comment 30 Gábor Stefanik 2008-10-07 12:01:54 PDT
(In reply to comment #29)
> Adding bug 448193 as there is a regression on border-radius with
> outset/inset/ridge/groove borders which makes us fail any standards compliancy
> testing on this combination.

Please actually add it, not just talk about adding it. (By the way, I added it.)
Comment 31 Zack Weinberg (:zwol) 2008-10-07 12:08:48 PDT
He added it, but I took it off (which I have now done again).  Please see the discussion in 448193 for why.
Comment 32 Zack Weinberg (:zwol) 2008-10-28 12:33:40 PDT
The core feature has landed; it doesn't make sense to have this cluttering up the wanted1.9.1+ list anymore.  Retitling to make present state of bug clearer.
Comment 33 Zack Weinberg (:zwol) 2009-03-16 11:33:09 PDT
adding some deps:

 - bug 382721 (dots and dashes don't continue around corners) 
 - bug 459945 (stripe borders have the wrong curve in between stripes)
Comment 34 Gábor Stefanik 2009-03-16 15:49:11 PDT
There is actuaally one more problem, though no bug has been filed for it: there are no color transitions between different-colored borders.
Comment 35 Zack Weinberg (:zwol) 2009-03-16 16:16:36 PDT
Thanks, I'd forgotten that one.  Filed bug 483696.
Comment 36 Samy Rabih 2009-11-26 06:20:48 PST
-moz-border-radius doesn't work on IMG tag (on Firefox 3.5.5 and 3.6b3) without a border width specified.
And if you specify this width, the "border" is rounded outside and squared inside.

So, -moz-border-radius cannot be used on the same way -webkit-border-radius is used : putting rounded corners on an IMG tag without any tricks (like using a div with border radius and the IMG as background).
Comment 37 David Baron :dbaron: ⌚️UTC-10 2009-11-26 14:25:36 PST
(In reply to comment #36)
> -moz-border-radius doesn't work on IMG tag (on Firefox 3.5.5 and 3.6b3) without
> a border width specified.
> And if you specify this width, the "border" is rounded outside and squared
> inside.

This sounds like bug 485501.  (I'm assuming you mean that the border gets rounded but the image itself doesn't get clipped at all.)
Comment 38 Samy Rabih 2009-11-26 23:20:03 PST
Yes, the border is rounded but not the image (in fact, I thought border-radius would act as a "corner-radius" (if it existed) should work, but the border-radius use is a little bit different)
Comment 39 Zack Weinberg (:zwol) 2010-01-25 12:27:28 PST
*** Bug 395674 has been marked as a duplicate of this bug. ***
Comment 40 Zack Weinberg (:zwol) 2010-01-25 12:35:54 PST
I just went through and added every bug I could find with 'border-radius' in the subject line to the dependencies of this bug, except the ones that I could prove had already been fixed.  Some of the remaining bugs may also have already been fixed, and some of the others may be duplicates of each other.

Bringing over what I just said in bug 395674: I think that before we drop the -moz- prefix on these properties, we should at a minimum fix bug 485501 (clip images to the border-radius) and bug 471643 (vertical percentages should be relative to box height, not width).  Bug 459144 (clip *all* content to the curve when overflow!=visible) and bug 382721 (dotted/dashed corners drawn as solid with border-radius) would also be nice but may be much harder to fix so I'm reluctant to make them block the property name.

I don't know if I'll have time to work on any of this in the near future.
Comment 41 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-01-25 15:31:50 PST
I don't think bug 459144 would be very hard to fix.
Comment 42 Zack Weinberg (:zwol) 2010-01-25 15:39:39 PST
dbaron was pessimistic about that 'way back when (I think it was on IRC) but it might be easier now that scrollframes don't have views.
Comment 43 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-01-25 16:03:38 PST
You just need a new display item, like nsDisplayClip but different.
Comment 44 Frank Yan (:fryn) 2010-03-19 20:59:13 PDT
Could we drop the -moz prefix now? Even IE9 has: http://blogs.msdn.com/ie/archive/2010/03/19/the-css-corner-about-css-corners.aspx
Comment 45 Gábor Stefanik 2010-03-20 12:02:09 PDT
And indeed, the spec is CR now. There is no reason to prefix it anymore.
Comment 46 Zack Weinberg (:zwol) 2010-03-20 19:28:40 PDT
The prefix should remain while there are still major bugs.  See comment 40.
Comment 47 Peter Gasston 2010-06-12 07:00:16 PDT
Safari 5 no longer has the -webkit- prefix for border-radius, so by the end of this year Firefox could be the only major browser without spec-compliant border-radius implementation.
Comment 48 Mike Beltzner [:beltzner, not reading bugmail] 2010-08-10 07:41:35 PDT
Is webkit's actually spec-compliant? I thought (a) the specification wasn't finished, and (b) the webkit implementation differed from the current/latest specification
Comment 49 Peter Gasston 2010-08-10 14:55:23 PDT
(In reply to comment #48)
> Is webkit's actually spec-compliant? I thought (a) the specification wasn't
> finished, and (b) the webkit implementation differed from the current/latest
> specification

Well the spec is still at Working Draft status, but Opera, WebKit (and soon IE9) all comply with the syntax that's in the current version - at least, I haven't run a battery of tests on it, but they all support it for length units (although not percentages) - that is, they all support the border-radius syntax with the slash, and all without the prefix.
Comment 50 Frank Yan (:fryn) 2010-08-10 15:03:21 PDT
(In reply to comment #49)
> Well the spec is still at Working Draft status, but Opera, WebKit (and soon
> IE9) all comply with the syntax that's in the current version - at least, I
> haven't run a battery of tests on it, but they all support it for length units
> (although not percentages) - that is, they all support the border-radius syntax
> with the slash, and all without the prefix.

Recognizing the W3C syntax does not necessarily imply specification compliance of the implementation. That would be like saying: just because the word 'smoking' also exists in French, if you ask for 'smoking' in France, you won't necessarily get anything related to a cigarette. (In fact, you'll probably get a tuxedo.)
Comment 51 Gavin 2010-08-10 15:30:33 PDT
I think we're going a little off topic here, its not important if or how well other browser developers have implemented this, its how Gecko handles 'border-radius' that's important.

I would love for Fx4.0 to at least drop the vendor specific prefix as I think it implements -moz-border-radius pretty well, and as its now the only browser (of the top 4) to not render anything for border-radius in their latest builds, it would be a shame if developers must add border-radius and then -moz-border-radius to implement this cross-browser.
Comment 52 fantasai 2010-08-11 10:42:27 PDT
Aside from the box-shadow section, the rest of the spec is effectively in CR. So the spec there is finished. As for Webkit's implementation, last I checked they did have spec compliance bugs. FWIW, I agree with Zack's comment 40.
Comment 53 Mike Beltzner [:beltzner, not reading bugmail] 2010-08-11 17:53:21 PDT
Up to dbaron/zweinberg to determine if they think that dropping the vendor prefix should block Firefox 4, and if that's the case we'll need a bug on that with the specific fixes required (maybe taking the list from comment 40) marked blocking2.0

I agree that removing the vendor-prefixes has WIN all over it, assuming that what we implement is what web authors will expect from non-vendor-prefixed descriptors.
Comment 54 Zack Weinberg (:zwol) 2010-08-11 18:03:05 PDT
(In reply to comment #53)
> Up to dbaron/zweinberg to determine if they think that dropping the vendor
> prefix should block Firefox 4

I want to say yes (given that all other vendors have, and we're taking flak) but, um, here I am dropping from full time to unpaid volunteer with very limited coding time as of Friday, and it appears that nobody else has time to do it either.
Comment 55 Emil Ivanov 2010-08-12 04:29:48 PDT
Opera have bugs with border-radius too but they dont use vendor prefix.
Comment 56 Zack Weinberg (:zwol) 2010-08-17 22:25:53 PDT
I have made the bugs listed in comment 40 ( bug 485501, bug 471643, bug 459144 ) block bug 471643, which is the bug that says "we should drop the vendor prefix".  dbaron agrees that these are the things that need to get fixed first.
Comment 57 Zack Weinberg (:zwol) 2010-08-18 09:41:45 PDT
I no longer work for Mozilla, I am deassigning myself from bugs I have no intention of working on as a volunteer.
Comment 58 David Baron :dbaron: ⌚️UTC-10 2010-09-05 13:41:55 PDT
For the record, I just filed bug 593717 on making outlines follow the border-radius curve instead of having a separate -moz-outline-radius.  My current thinking is that this does NOT block renaming -moz-border-radius to border-radius (bug 451134).

I also have patches in progress for the two remaining bugs that we agreed do block it.
Comment 59 Florian Bender 2012-12-22 15:55:26 PST
Bug 760358, Bug 652650 and maybe Bug 697645 should be added.
Comment 60 Zack Weinberg (:zwol) 2012-12-22 17:39:30 PST
(In reply to Florian Bender from comment #59)
> Bug 760358, Bug 652650 and maybe Bug 697645 should be added.

Concur.  For future reference, you can do that yourself by clicking on the (edit) next to the list of bugs that this one depends on (way up at the top) and then adding the bug numbers to the text box that appears.
Comment 61 Anil Shanbhag 2012-12-22 23:38:43 PST
For dashed borders, you can check https://bugzilla.mozilla.org/show_bug.cgi?id=652650

There is a implementation that I had implemented based on spec. Handles dashed borders along the elliptical corners. How it looked in firefox : http://gsocwithmozilla.wordpress.com/2011/07/31/basic-patch/. 

More sample output : https://github.com/anilshanbhag/border/tree/master/sample%20output. There is also a python implementation in pycairo used for reftest generation.
Comment 62 John 2013-08-03 07:20:25 PDT
The latest version of Firefox (22.0) is worse than the previous one... I have a button whose style is as follows:
  border-radius: 2em 2em 2em 2em;
  font-size: 110%;
  padding: 0.5em 1em;
  min-width: 7em;
  padding: 1px 1em;
This rendered fine with earlier versions of Firefox, but now the rounded courners are rotated in some weird way.

A screenshot for Firefox is here: https://dl.dropboxusercontent.com/u/18254707/button_firefox.jpg
The same thing with Chrome is here: https://dl.dropboxusercontent.com/u/18254707/button_chrome.jpg
Comment 63 Florian Bender 2013-08-03 08:02:48 PDT
(In reply to John from comment #62)
> A screenshot for Firefox is here:
> https://dl.dropboxusercontent.com/u/18254707/button_firefox.jpg
> The same thing with Chrome is here:
> https://dl.dropboxusercontent.com/u/18254707/button_chrome.jpg

Do you have a link or standalone testcase? Otherwise this will be hard to debug.
Comment 64 John 2013-08-04 05:01:47 PDT
Sure, try this:

<html>
<head>
  <title>Firefox border-radius bug demo</title>
  <style type="text/css">
    BUTTON {
      border-radius: 2em 2em 2em 2em;
      font-size: 110%;
      padding: 0.5em 1em;
      min-width: 7em;
      padding: 1px 1em;
    }
  </style>
</head>
<body>
  <button type="submit">Submit</button>
</body>
</html>
Comment 65 Florian Bender 2013-08-04 06:06:35 PDT
WFM on latest Firefox 23 through 25 on Mac with your code from comment 64.

If you still experience issues, maybe on a specific platform only, please file a new bug (you should have done that anyway because you are having a specific issue – this is a tracking bug for several issues).
Comment 66 John 2013-08-04 07:51:42 PDT
(In reply to Florian Bender from comment #65)
> WFM on latest Firefox 23 through 25 on Mac with your code from comment 64.
> 
> If you still experience issues, maybe on a specific platform only, please
> file a new bug (you should have done that anyway because you are having a
> specific issue – this is a tracking bug for several issues).

OK, have just filed it as a new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=901336

FYI, I'm using Windows 7 (64 bit).
Comment 67 Erwann Mest 2013-09-27 03:22:07 PDT
border-radius bugged on Firefox?

-> http://grab.by/qEAS left: firefox aurora, right: chrome canary

OS: Mac OS X 10.7.5
Firefox version: 26.0a2 (2013-09-24)

Note You need to log in before you can comment on or make changes to this bug.