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.
Created attachment 115599 [details]
Bugged / Expected Result
Can you please upload a html test case (e.g. the one you used to generate the attached images)
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.
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)
I've just encountered this dreadful bug myself. Why is this still unconfirmed and why hasn't anyone been assign to fix this?
I am confirming this bug as well. Please fix
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. :'(
Another confirmation here ...
I have been experiencing this problem for about a year. Please fix.
Position static works:
Position relative fails:
Position absolute fails:
Position fixed fails:
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/
And another confirmation... Please review/address this issue! It's quite a pain to deal with, and has been for quite some time.
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.
Can confirm the same behavior for children elements positioned other than static.
Firefox gives the expected results.
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
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 !
waiting for this fix for years now. please fix.
The same bug #77572
Still unfixed after almost one year.
Nothing until now?
Even Internet Explorer support that!
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.
This issue has been fixed, marking as resolved