Bug 72619 – border-radius does not "hide" inner content when overflow:hidden is specified

• Component: CSS
• Status: RESOLVED FIXED

[Manolis Kp.]

When an HTML element has border-radius specified and overflow:hidden, an element contained within, is visible outside the border at the corners of the parent element while it shouldn't.

[Manolis Kp.]

Created attachment 115599 [details]
Bugged / Expected Result

[Shane Stephens]

Can you please upload a html test case (e.g. the one you used to generate the attached images)

[Manolis Kp.]

Created attachment 117350 [details]
The HTML file that will generate the bug in webkit

As you will notice there is one div element inside another, in the html file.
The outer div has position:relative style as well as overflow:hidden.
The inner div is larger than the outer div, it gets hidden but not at the corner areas.
I noticed that if the outer div does not specify position:relative and the inner does not specify position:absolute then it works as expected.
So it seems there is a problem with the positioning types.

However the above html code works well with Firefox (and as expected).

I find that it's sufficient for the bug to be triggered whenever the outer div has overflow:hidden, border-radius, and a position style of anything other than static (relative, absolute, fixed).
Any extra css can be removed, though having a border or a background color on the outer div helps to make the bug visible.

As this bug still has a status of 'unconfirmed' I'd also like to confirm I'm seeing this behaviour in Webkit browsers.

I'd imagine the approach of using a 'responsive' sized container to crop a static image is becoming more frequent, so having consistent spec interpretation/implementation that matches user expectations is important.

[Manolis Kp.]

This bug has been submitted months ago, and its a pretty important one as it causes unexpected behavior when border-radius is used. Why is it still unconfirmed? The HTML provided clearly generates the bug. (using both Chrome 17.0.963.44 beta and Safari 5.1.2, including Safari for iOS)

[S3]

I've just encountered this dreadful bug myself. Why is this still unconfirmed and why hasn't anyone been assign to fix this?

[Misha Reyzlin]

I am confirming this bug as well. Please fix

[Dave]

Is there any progress on this? It's definitely still present and I've even seen blog posts about the issue dating back to 2009.

I was most saddened that I this works in FF & IE9 and even in IE7 & 8 with a little help from PIE.htc. 

I guess it's not had any movement. :'(

[Zero Piraeus]

Another confirmation here ...

I have been experiencing this problem for about a year.  Please fix.

[Charles Dorner]

Position static works:

http://jsfiddle.net/7Z5U4/


Position relative fails:

http://jsfiddle.net/ex47z/2/


Position absolute fails:

http://jsfiddle.net/PDVwA/1/


Position fixed fails:

http://jsfiddle.net/RcRKH/2/

[Charles Dorner]

Messed up the links, use these

Position static works: http://jsfiddle.net/7Z5U4/

Position relative fails: http://jsfiddle.net/ex47z/2/

Position absolute fails: http://jsfiddle.net/RcRKH/2/

Position fixed fails: http://jsfiddle.net/jCdL3/

[M Andersen]

And another confirmation... Please review/address this issue! It's quite a pain to deal with, and has been for quite some time.

[Benoît Burgener]

It's even more annoying with overflow-x:auto & overflow-y:hidden where you can't set the border-radius to the child since it scroll. Please, do something.

[Mark Smits]

Can confirm the same behavior for children elements positioned other than static.
Firefox gives the expected results.

[Jens Christian Rodi Hansen]

One more confirmation. So happy to find that I'm looking at at bug (not me missing something in the css).

I see the problem with a div>ul>li structure. The div have the rounded corners and overflow:hidden, the ul has position:absolute and the li's have position:relative. Both ul and li have a background color, which exceeds the rounded corners of the parent div.

Works fine in Firefox 14, but fails in official Chrome and Version 23.0.1244.0

referincing Chromium bug: http://code.google.com/p/chromium/issues/detail?id=62363

additional test case: http://jsfiddle.net/N2cXJ/1/

     Safari 5: FAIL
    Chrome 21: FAIL
   Firefox 15: OK
         IE 9: OK

[Paul Irish]

In addition to http://crbug.com/62363 , looks like http://crbug.com/71639 is also downstream.

Bonus: 71639 is only one digit difference from this bug ID, 72619 !

[Ido Rosenthal]

waiting for this fix for years now. please fix.

[Binyamin]

The same bug #77572

[S3]

Still unfixed after almost one year.

[David Rodrigues]

Nothing until now?
Even Internet Explorer support that!

https://code.google.com/p/chromium/issues/detail?id=71639#c17

[Jens Christian Rodi Hansen]

I can see that the seemingly related bug 71639 (https://code.google.com/p/chromium/issues/detail?id=71639) was fixed in the latest canary build of Chrome (24.0.1303.0).

It did unfortunately not fix this bug.

[Manolis Kp.]

This issue has been fixed, marking as resolved