I'm experiencing the same problem, here is my test code and a screenshot.

yourBox
{
	background: #505050;
	-webkit-border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-box-shadow: inset 0 1px 6px rgba( 0, 0, 0, 0.9 );
	-moz-box-shadow: inset 0 1px 6px rgba( 0, 0, 0, 0.9 );
}

	chromium_boxshadow_rounded_bug.png 747 bytes   View   Download

Bulk update

you can work around this by defining the border 

yourBox
{
	background: #505050;
	-webkit-border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-box-shadow: inset 0 1px 6px rgba( 0, 0, 0, 0.9 );
	-moz-box-shadow: inset 0 1px 6px rgba( 0, 0, 0, 0.9 );

        border:1px solid #505050;
}

@jhlagado: it looks slightly better but far from a rounded corner ;)

Assigning to someone who might actually have a chance to fix this.

 Issue 31448  has been merged into this issue.

This looks like the same bug:

http://stackoverflow.com/questions/2937731/box-shadow-and-border-radius-bug-in-chrome

 Issue 46212  has been merged into this issue.

 Issue 44460  has been merged into this issue.

 Issue 42656  has been merged into this issue.

 Issue 45751  has been merged into this issue.

I have an example too, which works fine in Mozilla but fails in Chrome on form inputs:

http://www.devseo.co.uk/examples/beautiful-css3-form/

 Issue 47740  has been merged into this issue.

I'm not actively working on this, so I'm unowning in the hopes that someone adopts it.

This fixes the problem for me:

Index: RenderBoxModelObject.cpp
===================================================================
--- RenderBoxModelObject.cpp	(revision 62294)
+++ RenderBoxModelObject.cpp	(working copy)
@@ -1680,7 +1680,7 @@
             context->save();
 
             if (hasBorderRadius)
-                context->clip(Path::createRoundedRectangle(rect, topLeft, topRight, bottomLeft, bottomRight));
+                context->canvasClip(Path::createRoundedRectangle(rect, topLeft, topRight, bottomLeft, bottomRight));



I'm not entirely sure why, though. It looks like the rounded rect hack that agl put in gets confused with inset shadows, and it's not needed anyway, so sidestepping makes the problem go away. agl, since this is potentially a one-line fix (it just needs a better explanation than "uhh – now it works!" :-) ) and in code you wrote, do you want to take this on?

Else, please assign to me and I'll dig some more.

And for my reference: http://trac.webkit.org/changeset/49641 (patch where agl added canvasClip()).

I think my patch above is mostly correct. It seems that agl's antialiasing hack doesn't work with shadows. Non-inset shadows are clipped by a call to context->clipOut() (first big branch in RenderBoxModelObject::paintBoxShadow), which happens to not use the antialiasing hack. Inset shadows call context->clipPath(), which uses the antialiasing hack in GraphicsContext::clipPath(). So the patch makes inset shadows work as nice as normal shadows.

It's not the prettiest patch as it somewhat exposes skia implementation details to RenderBoxModel, but in a way that's already happened in http://trac.webkit.org/changeset/49641 .

(Note that using skia's normal clipping for shadows isn't all that great: Since skia's clip paths use only 1 bit of transparency – http://www.imperialviolet.org/2009/09/02/anti-aliased-clipping.html – shadows are pretty aliased. This is for example very visible when drawing a div with border radius 20px, background-color:rgba(255, 0, 0, 0.5), border:3px solid green, and -webkit-box-shadow:4px 4px 8px black. Note the ugly edge with color bleeding and all.)

I guess I'll try to get the patch above landed in webkit.

https://bugs.webkit.org/show_bug.cgi?id=41576

That didn't go so well :-)

Mitz is right though, we need some way to clip shadows with antialiasing – see screenshot (in addition to the aliased shadow, there are also some jpeg artifacts due to nxclient, sorry about that).

	Picture 20.png 88.6 KB   View   Download

For status see http://neugierig.org/software/chromium/notes/


AGL

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

So, nobody is working on this? I have tested Safari on Windows and works as it should. 

I can see too that there's an inset shadow when not setting border. I mean:

.field {
    border: 1px solid #333;
    -webkit-border-radius: 15px;
    -webkit-box-shadow: inset 0 1px 1px #999;
}

Will show this bug, but:

.field {
    -webkit-border-radius: 15px;
}

Will show an inset shadow properly rendering!! I can´t understand why.

article about these bugs in russian (but everything is clear and with sources):
http://habrahabr.ru/blogs/css/103170/

still no fix for this bug in the latest verion of Chrome For Windows(6.0.472.53)

example of the error

http://cssdesk.com/KKHC7

cssdesk.html 836 bytes   View   Download

Crazy. So, if this works in Safari... can someone confirm the patch has been merged into Webkit? If so, why does Chromium not have it yet?

Still here in the beta (7.0.517.24). Are you guys waiting on webkit to fix this?

Safari uses Cor

eGraphics, while chrome uses Skia for drawing on windows and linux. This is mostly a Skia bug.

Opened an issue there and I'm cross-linking >> https://code.google.com/p/skia/issues/detail?id=82

WebKit assumes that it has immediate mode clipping which Skia doesn't do. See http://neugierig.org/software/chromium/notes/2010/07/clipping.html

Fixing this means rewriting clipping in Skia and the main Skia developer changed jobs.

You're correct that this has been hanging around for too long. However, given the vitriolic abuse that usually ends up being thrown around on graphics issues, I'm not too keen to go near them now.

 Issue 61185  has been merged into this issue.

 Issue 64674  has been merged into this issue.

Is this fixed as of http://trac.webkit.org/changeset/74089 ?

Yes. I filed  issue 67723  for the polish stuff that's left.

 Issue 65587  has been merged into this issue.

 Issue 73312  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)