Bug 88587 – Z coordinate incorrect in -webkit-transform-origin Safari

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Christopher Cameron]

Created attachment 146404 [details]
Sample image rendered in Chrome

It appears that the Z coordinate of -webkit-transform-origin does not behave correctly on Safari.

If the point <x,y,z> is specified by -webkit-transform-origin, and the transformation matrix T is specified by -webkit-transform, then the overall transformation should be:
  [1 0 0 x]       [1 0 0 -x]
  [0 1 0 y] * T * [0 1 0 -y]
  [0 0 1 z]       [0 0 0 -z]
  [0 0 0 1]       [0 0 0  1]
It appears that in Safari, the transformation is actually:
  [1 0 0 x]       [1 0 0 -x]
  [0 1 0 y] * T * [0 1 0 -y]
  [0 0 1 0]       [0 0 0 -z]
  [0 0 0 1]       [0 0 0  1]
Note the zero in row 3 column 4 of the leftmost matrix.  Consequently, the resulting Z position is incorrect.

I've attached a stripped-down test (from the Chromium bug) which shows this behavior, along with pictures of its rendering.  In the example, the top image shows text that should have no transformation applied to it, but it has a translation in the Z dimension as a consequence of this bug.  The middle image shows an ordinary rotateY(180deg), which renders correctly on Safari.  The bottom image does a rotateY(180deg) around non-zero Z-origin, which is also impacted by this bug on Safari.

[Christopher Cameron]

Created attachment 146405 [details]
Rendering in Safari

[Christopher Cameron]

Created attachment 146406 [details]
Source HTML file

[Christopher Cameron]

Adding myself and Simon Fraser to CC.

[Simon Fraser (smfr)]

Is this this same as the issue described by http://jsfiddle.net/fnJyd/ ?

[Christopher Cameron]

(In reply to comment #4)
> Is this this same as the issue described by http://jsfiddle.net/fnJyd/ ?

> When changing the value of a transform-origin's z component 
> Safari seems to automatically translate the element to the 
> specificed position if a transform has been defined.

Yes, this is the same issue.

[Simon Fraser (smfr)]

*** Bug 91494 has been marked as a duplicate of this bug. ***

[Simon Fraser (smfr)]

<rdar://problem/14180947>

[Glen Huang]

Any progress on this one? Allowing specifying the z axis for transform-origin can greatly simplify the creation of a transformed cube for example.

Blink has already fixed it, I wonder if webkit can borrow the code directly?

[Simon Fraser (smfr)]

Do you have a link to the chromium bug?

[Glen Huang]

Actually it seems blink uses different code.

I believe this chrome issue is what leads Christopher to open this bug report:
https://code.google.com/p/chromium/issues/detail?id=130339

[Simon Fraser (smfr)]

Created attachment 245187 [details]
Testcase

[Tomas Roggero]

Another sample, in this case with animation https://codepen.io/tomasdev/pen/eydWQj

If you compare that demo in Chrome vs Safari iOS you will see the origin, even though it's explicitly set, is not calculated the same way.

[Tomas Roggero]

Just modified my pen to include a working version, that has an extra wrapper with the proper Z-translate.

[Simon Fraser (smfr)]

Still reproduces.

[Ahmad Saleem]

I am able to reproduce this still in Safari Technical Preview 154 using attached test case and Safari show "different" container size for both compared to other browsers (Chrome Canary 108 and Firefox Nightly 107), which shows it of same size. Thanks!

Also changing this to "Layout and Rendering" category.

[Ahmad Saleem]

I think this is now fixed because Safari 16.3, Chrome Canary 111 are matching each other in both "Source HTML File" and "Testcase".

@smfr - can we close this now?

[Simon Fraser (smfr)]

I recall Matt fixing something like this.

[Matt Woodrow]

*** This bug has been marked as a duplicate of bug 245353 ***