Closed Bug 536061 Opened 15 years ago Closed 14 years ago

-moz-box-shadow doesn't well-support -moz-transform: translate() and/or rotate()


(Core :: Web Painting, defect, P2)




Tracking Status
blocking2.0 --- final+


(Reporter: ivan.enderlin, Assigned: MatsPalmgren_bugz)




(4 keywords, Whiteboard: [3.6.x])


(4 files)

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: <> or the PNG : <>.

Reproducible: Always
Keywords: css-moz, css3
works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091201 Firefox/3.5.6

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091231 Namoroka/3.6b6pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre
Ever confirmed: true
Keywords: regression
Flags: blocking1.9.2?
Component: DOM: CSS Object Model → Layout: View Rendering
QA Contact: general → layout.view-rendering
Regression range would be great.
build range

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

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091007 Namoroka/3.6b1pre
Severity: normal → blocker
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.
Flags: blocking1.9.2? → blocking1.9.2-
Whiteboard: [3.6.x]
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.
Assignee: nobody → roc
blocking2.0: --- → ?
blocking2.0: ? → final+
Priority: -- → P2
Summary: Box-shadow doesn't well-support a translated transformation → -moz-box-shadow doesn't well-support -moz-transform: translate() and/or rotate()
Severity: blocker → normal
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]
Attached patch Patch rev. 1Splinter Review
Simple fix.
Assignee: roc → matspal
Attachment #490561 - Flags: review?(roc)
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

Attachment #490561 - Flags: review?(roc) → review+
(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...
Keywords: testcase
No longer blocks: 601512
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
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.)
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.