User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091219 Minefield/3.7a1pre Build Identifier: When applying a -moz-box-shadow on a -moz-transform: translate(), the shadow isn't well-placed. It's shifted. Look the source: <http://mozilla.hoa-project.net/Bug/Transform_and_shadow.html> or the PNG : <http://mozilla.hoa-project.net/Bug/Transform_and_shadow.png>. Reproducible: Always

works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 broken: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091231 Namoroka/3.6b6pre broken: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre

Regression range would be great.

build range works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091006 Namoroka/3.6b1pre broken: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091007 Namoroka/3.6b1pre

Bug 513082 and maybe bug 514670 seem like possibilities after reading http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?startdate=2009-10-06+00%3A00%3A00&enddate=2009-10-07+08%3A00%3A00

I've changed the bug's importance from normal to blocker (because of its regression nature).

My instinct is that this isn't a hard release blocker, and to clean it up in a 3.6.x release, but I don't know how common these sorts of things are. I would have expected to see more web-compatibility bugs if it was a common pattern, though. David, Roc: thoughts on blocking?

It's unlikely to be a Web-compatibility problem since it's in the interaction of two features that aren't supported in IE. But it could affect things people are working on using those new features. It would be good to know what the underlying problem is, but I think it's probably something that we could fix in a .1 release.

inset shadows seem to be OK, so I'm guessing that maybe this is related to nsDisplayBoxShadowOuter::ComputeVisibility

So this used to work? That's odd, since bug 514670 only changed behaviour if the frame had border radii.

I think bug 513082 is the more likely cause.

The mozilla-central regression range, from Linux x86-64 nightlies, is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=db6d2486737d&tochange=3756cdca8b54

I confirmed via try server that http://hg.mozilla.org/mozilla-central/rev/b540248e3163 is broken and http://hg.mozilla.org/mozilla-central/rev/6bfb2b05290f works, which means this is in fact a regression from http://hg.mozilla.org/mozilla-central/rev/b540248e3163 .

this attachment shows the -moz-box-shadow bug when using it with -moz-transform. webkit and opera have a good behavior. firefox nitghly x86 and x86_64 Linux builds are also affected.

See also testcase in duplicate bug 561119 - attachment 440798 [details]

Simple fix.

There's only reftest for -moz-transform: translate(), shouldn't the test for -moz-transform: rotate() be included as well?

Comment on attachment 490561 [details] [diff] [review] Patch rev. 1 Thanks!

(In reply to comment #22) > There's only reftest for -moz-transform: translate(), shouldn't the test for > -moz-transform: rotate() be included as well? It doesn't really matter, the underlying code paths are the same.

Will push as soon as my Try run is green...

I tried backporting the patch to 1.9.2, but it didn't seem to work. Maybe I did something wrong, though. And it looks like on 1.9.2 we need to fix the is-themed case in nsDisplayBackground as well. (I see transformed form controls failing in a similar way.)