New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 706231: CSS 3D transforms with perspective() are inside out (farther objects appear larger)

Reported by, Mar 29 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Create a 3D CSS layout, in which some elements have different z levels.
2. Add a `perspective()` function at the front of the element's transformation stack.

In the linked CodePen, the relevant example is the second SVG.  The first SVG demonstrates the lack of support for `transform-style: preserve-3d` in SVG content (which I'm going to assume is a known issue).

The second SVG is supposed to replace the need for preserve-3d by using `perspective()` in the individual element `transform` properties to replace the perspective from the parent.  The added transforms should have the same result as the perspective/perspective-origin properties in the first SVG.

What is the expected behavior?
In a supporting browser, both SVGs should be identical.  The shapes (or edges of shapes) that are transformed into negative Z coordinates should be rendered smaller than the equivalent lengths at the 0 z coordinate.

Firefox (54 tested) gets it right, albeit with blurry scaling issues.

What went wrong?
Safari and Chrome (including 59.0.3054.0 canary) seem to reverse the perspective scaling from `perspective()` functions: the elements with negative z positions are rendered larger, instead of smaller.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? N/A 

Did this work before? N/A 

Does this work in other browsers? No
 Safari 10

Chrome version: 57.0.2987.110  Channel: stable
OS Version: 10.0
Flash Version:

Comment 1 by, Mar 29 2017

Components: -Blink Blink>CSS
Labels: Needs-Triage-M57

Comment 2 by, Mar 30 2017

Status: Available (was: Unconfirmed)

Comment 3 by, Mar 30 2017

Labels: Hotlist-Interop

Comment 4 by, Mar 30 2017

Labels: Update-Monthly

Comment 5 by, Jul 26 2017

Labels: -Update-Monthly Update-Quarterly

Comment 6 by, Nov 27 2017

Labels: ApproachableBug
I measured the output at the link and the "side" rectangles do seem to get bigger in the wrong direction. I suspect we're missing a minus sign somewhere...

Comment 7 by, Dec 6 2017

Labels: -Update-Quarterly

Comment 8 by, Dec 6

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit - Your friendly Sheriffbot

Comment 9 by, Dec 12

Status: Fixed (was: Untriaged)
The second box now renders correctly and is identical to FF.

Comment 10 by, Dec 17

In what version is this fixed? I just tested in Canary and am still seeing the perspective backwards (back of the box is drawn wider than the front).

Attached is the correct rendering, from MS Edge, versus the incorrect rendering in Chrome Canary
Version 73.0.3642.0 (Official Build) canary (64-bit)
3Dperspective .MSEdge.png
3.9 KB View Download
5.5 KB View Download

Comment 11 by, Jan 6

Components: -Blink>CSS Blink>SVG
Status: Untriaged (was: Fixed)

Comment 12 by, Jan 7

Status: Available (was: Untriaged)

Comment 13 by, Jan 7

Note: the "backwards" part is likely an optical illusion.  Measuring locally, it appears we just ignore the perspective -- the front/back are identical rects, sides are parallelograms.

Comment 14 by, Jan 7

Yes, what we do is simple "drop" all matrix components outside of the 3x2 affine bit (TransformationMatrix::ToAffineTransform). So any z bits will make into the transform itself, but the perspective will not actually apply to the/a shape. HTML content will be treated in the same way (MakeMatrixRenderable) for the (likely uncommon) case when we don't have accelerated compositing.

Sign in to add a comment