Bug 88587 - Z coordinate incorrect in -webkit-transform-origin Safari
Summary: Z coordinate incorrect in -webkit-transform-origin Safari
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.7
: P2 Normal
Assignee: Simon Fraser (smfr)
Keywords: InRadar
: 91494 (view as bug list)
Depends on:
Reported: 2012-06-07 15:58 PDT by Christopher Cameron
Modified: 2018-12-01 11:35 PST (History)
7 users (show)

See Also:

Sample image rendered in Chrome (75.47 KB, image/png)
2012-06-07 15:58 PDT, Christopher Cameron
no flags Details
Rendering in Safari (97.27 KB, image/png)
2012-06-07 15:58 PDT, Christopher Cameron
no flags Details
Source HTML file (1.91 KB, text/html)
2012-06-07 15:59 PDT, Christopher Cameron
no flags Details
Testcase (1.39 KB, text/html)
2015-01-22 18:21 PST, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Cameron 2012-06-07 15:58:13 PDT
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.
Comment 1 Christopher Cameron 2012-06-07 15:58:45 PDT
Created attachment 146405 [details]
Rendering in Safari
Comment 2 Christopher Cameron 2012-06-07 15:59:05 PDT
Created attachment 146406 [details]
Source HTML file
Comment 3 Christopher Cameron 2012-06-07 16:00:23 PDT
Adding myself and Simon Fraser to CC.
Comment 4 Simon Fraser (smfr) 2012-06-07 16:05:39 PDT
Is this this same as the issue described by http://jsfiddle.net/fnJyd/ ?
Comment 5 Christopher Cameron 2012-06-07 16:07:40 PDT
(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.
Comment 6 Simon Fraser (smfr) 2012-07-18 12:37:04 PDT
*** Bug 91494 has been marked as a duplicate of this bug. ***
Comment 7 Simon Fraser (smfr) 2013-06-18 16:05:53 PDT
Comment 8 Glen Huang 2015-01-21 22:32:21 PST
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?
Comment 9 Simon Fraser (smfr) 2015-01-22 08:34:01 PST
Do you have a link to the chromium bug?
Comment 10 Glen Huang 2015-01-22 17:59:18 PST
Actually it seems blink uses different code.

I believe this chrome issue is what leads Christopher to open this bug report:
Comment 11 Simon Fraser (smfr) 2015-01-22 18:21:02 PST
Created attachment 245187 [details]
Comment 12 Tomas Roggero 2017-12-21 20:14:20 PST
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.
Comment 13 Tomas Roggero 2017-12-21 20:36:19 PST
Just modified my pen to include a working version, that has an extra wrapper with the proper Z-translate.
Comment 14 Simon Fraser (smfr) 2018-12-01 11:35:25 PST
Still reproduces.