New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 539 users

Issue metadata

Status: Verified
Last visit > 30 days ago
Closed: Dec 2010
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome
Pri: 2
Type: Compat

issue 48277
issue 67723

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 29427: Inset box shadow escapes content when border radius present

Reported by, Dec 4 2009 Project Member

Issue description

What steps will reproduce the problem?

Create a div with rounded corners and an inset box shadow.

<div style="
  border: 1px solid black;
  width: 100px;
  height: 100px;
  -webkit-box-shadow: inset 2px 2px 2px red;
  -webkit-border-radius: 10px;
  -moz-box-shadow: inset 2px 2px 2px red;
  -moz-border-radius: 10px;

What is the expected output? What do you see instead?

The shadow must not escape the content.

It seems like the inset box shadow ignores the rounded corners.

This works correctly in Safari and Chrome on Mac. It fails on Chrome Windows and Linux so it is probably 
Skia issue.

Comment 1 Deleted

Comment 2 Deleted

Comment 3 by, Jan 14 2010

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

	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 );
747 bytes View Download

Comment 4 by, Apr 2 2010

Labels: Mstone-6
Bulk update

Comment 5 by Deleted ...@, Apr 8 2010

you can work around this by defining the border 

	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;

Comment 6 by, Apr 8 2010

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

Comment 7 Deleted

Comment 8 by, Apr 22 2010

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

Comment 9 by, Apr 27 2010

 Issue 31448  has been merged into this issue.

Comment 10 Deleted

Comment 11 Deleted

Comment 12 Deleted

Comment 14 Deleted

Comment 15 Deleted

Comment 16 by, Jun 20 2010

 Issue 46212  has been merged into this issue.

Comment 17 by, Jun 20 2010

 Issue 44460  has been merged into this issue.

Comment 18 by, Jun 20 2010

 Issue 42656  has been merged into this issue.

Comment 19 by, Jun 21 2010

 Issue 45751  has been merged into this issue.

Comment 20 by, Jun 22 2010

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

Comment 21 by, Jun 28 2010

 Issue 47740  has been merged into this issue.

Comment 22 by, Jun 29 2010

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

Comment 23 by, Jul 3 2010

This fixes the problem for me:

Index: RenderBoxModelObject.cpp
--- RenderBoxModelObject.cpp	(revision 62294)
+++ RenderBoxModelObject.cpp	(working copy)
@@ -1680,7 +1680,7 @@
             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.

Comment 24 by, Jul 3 2010

And for my reference: (patch where agl added canvasClip()).

Comment 25 by, Jul 4 2010

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 .

(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 – – 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.

Comment 27 by, Jul 4 2010

Status: Available
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

Comment 28 Deleted

Comment 29 Deleted

Comment 30 by, Jul 9 2010

Comment 31 by, Jul 12 2010

Labels: -Skia

Comment 32 by, Jul 21 2010

Labels: Mstone-X

Comment 33 by, Aug 26 2010

Labels: Fidelity

Comment 34 by, Aug 28 2010

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.

Comment 35 by, Sep 1 2010

article about these bugs in russian (but everything is clear and with sources):

Comment 36 by, Sep 3 2010

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

Comment 37 Deleted

Comment 38 Deleted

Comment 39 by, Sep 27 2010

example of the error
836 bytes View Download

Comment 40 by, Oct 5 2010

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?

Comment 41 by, Oct 5 2010

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

Comment 42 by, Oct 5 2010

Safari uses Cor

Comment 43 by, Oct 5 2010

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

Comment 44 by, Oct 5 2010

Opened an issue there and I'm cross-linking >>

Comment 45 by, Oct 5 2010

Labels: Restrict-AddIssueComment-Commit
WebKit assumes that it has immediate mode clipping which Skia doesn't do. See

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.

Comment 46 by, Oct 29 2010

 Issue 61185  has been merged into this issue.

Comment 47 by, Nov 29 2010

 Issue 64674  has been merged into this issue.

Comment 48 by, Dec 21 2010

Status: Assigned
Is this fixed as of ?

Comment 49 by, Dec 21 2010

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

Comment 50 by, Dec 23 2010

 Issue 65587  has been merged into this issue.

Comment 51 by, Mar 13 2011

 Issue 73312  has been merged into this issue.

Comment 52 by, Mar 23 2011

Labels: -Area-Compat-Web bulkmove Area-Compat

Comment 53 by, Jun 26 2012

Blocking: -48277 -67723 chromium:48277 chromium:67723
Labels: VerifyIn-21

Comment 54 by, Jul 16 2012

Status: Verified

Comment 55 by, Mar 10 2013

Project Member
Blocking: -chromium:48277 -chromium:67723 chromium:48277 chromium:67723
Labels: -Type-Bug -Area-Internals -Internals-Skia -Area-Compat Cr-Internals-Skia Type-Compat Cr-Internals

Sign in to add a comment