Bug 88587 - Z coordinate incorrect in -webkit-transform-origin Safari
: Z coordinate incorrect in -webkit-transform-origin Safari
Status: NEW
Product: WebKit
Classification: Unclassified
Component: New Bugs
: 528+ (Nightly build)
: Macintosh Intel Mac OS X 10.7
: P2 Normal
Assigned To: Simon Fraser (smfr)
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 15:58 PDT by Christopher Cameron
Modified: 2015-01-22 18:21 PST (History)
5 users (show)

See Also:


Attachments
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
<rdar://problem/14180947>
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:
https://code.google.com/p/chromium/issues/detail?id=130339
Comment 11 Simon Fraser (smfr) 2015-01-22 18:21:02 PST
Created attachment 245187 [details]
Testcase