Bug 40414 – Fetching inline style gives different matrix for rotate(90deg) than getComputedStyle

• Component: CSS
• Status: REOPENED

[Dirk Schulze]

Created attachment 58354 [details]
Test case

CSS Transforms rotate(90deg) make's responing matrix uninvertvible. See alert on attached text. Matrix is 0,1,-1,0,0,0

[Simon Fraser (smfr)]

I don't see a test for the matrix being uninvertible.

[Dirk Schulze]

(In reply to comment #1)
> I don't see a test for the matrix being uninvertible.

I get (0,1,-1,0,0,0). That means a = d = 0. Do you get somthing different?

[Dirk Schulze]

But I get correct values with getComputedStyle.

[Dirk Schulze]

The calculation was correct, sorry. A rotation of 90deg means that 'a' gets cos(90/180*pi) and cos(pi/2) is 0.

[Simon Fraser (smfr)]

I don't know why getComputedStyle would return a different value in this case. Reopening this bug to figure out why fetching inline style gives a different answer.

[Dirk Schulze]

(In reply to comment #5)
> I don't know why getComputedStyle would return a different value in this case. Reopening this bug to figure out why fetching inline style gives a different answer.

The difference is not quite big matrix(1,77321e-16, 1, -1, 1,77321e-16, 0, 0) to matrix(0,000000, 1,000000, -1,000000, 0,000000, 0,000000, 0,000000). With different code paths:

getComputedStyle:
var parent = document.getElementById('parent');
var matrix = window.getComputedStyle(parent).webkitTransform;
alert(matrix);

inline style:
var firstMatrix = new WebKitCSSMatrix(document.getElementById('parent').style.webkitTransform);
alert(firstMatrix);

[Chris Marrin]

Those two matrices are, for all intents and purposes, identical. The only difference is rounding.

The source of the rounding error may be one of the several places we use single precision floating point numbers in TransformationMatrix::rotate3d(). All the use of single precision in this file is a holdover from when the matrix itself was single precision. None of the uses of single precision here seem dangerous. I think they will all up-convert before being used. And the numbers are all 1.0f or 2.0f, which I believe are exactly represented in single precision. But there may be places where single precision math is being performed.

It could also be just general precision loss. We need to convert to radians, which is inherently lossy. But this seems like greater loss than that.

Finally, there could be places outside the TransformationMatrix code where the values could be getting shortened. But that seems unlikely for 90 degrees, since we store rotation values in degrees directly in the style declaration. So there's no conversion there.

At any rate, all the use of single precision in TransformationMatrix should be removed.

[Ahmad Saleem]

Based on attached test cases - I get following values across browsers:


Safari 15.6 - transform: matrix(6.123233995736766e-17, 1, -1, 6.123233995736766e-17, 0, 0)

Chrome Canary 106 - transform: matrix(6.123233995736766e-17, 1, -1, 6.123233995736766e-17, 0, 0)

Firefox Nightly 104 - transform: matrix(2.220446049250313e-16, 1, -1, 2.220446049250313e-16, 0, 0)

Safari and Firefox match each other but differ from Firefox Nightly slightly. Just wanted to share updated results as of today. Thanks!

[Brent Fulgham]

Seems like this warrants some investigation. Thank you for testing!

[Radar WebKit Bug Importer]

<rdar://problem/97496245>