Firefox doesn't order certain css 3d elements correctly when using css transform.




5 years ago
4 years ago


(Reporter: mccutchon.brian, Unassigned)


23 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

Create two or more elements, use css to apply a perspective to their container, and give them an x or y rotation. 

Actual results:

If they are overlapping, chances are that they will not overlap correctly. This can make more complicated css transforms look really messy. For a live example, see

Expected results:

In the above example, the two elements should intersect. I don't know how else to explain it, but it only works correctly in Safari, not Firefox or Google Chrome.
Component: Untriaged → Layout
Product: Firefox → Core
Summary: Firefox doesn't order certain css 3d elements correctly. → Firefox doesn't order certain css 3d elements correctly when using css transform.
WFM on Windows 7 with Firefox 10 ESR, 17 ESR, 24 ESR and Trunk.
Maybe OSX specific. Can you still repro?
Flags: needinfo?(mccutchon.brian)
Created attachment 8359561 [details]
Comparison Firefox(one the left) - Safari (on the right)

I can already see the difference between Firefox and Safari.
I've attached a screenshot of the current behavior, not sure is the one expected.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0
Ok, thanks. Seeing this now too.
In addition of Chrome rendering like Firefox, MSIE 11 is doing the same.

Comment 4

5 years ago
Yes, that's exactly what I meant. The Safari behavior is expected. When one plane passes through another, you would expect the graphics to reflect this. It's surprising that only Safari gets it right.
Flags: needinfo?(mccutchon.brian)

Comment 5

5 years ago
bug 725299 also describes this.

Comment 6

5 years ago
Not exactly. This bug has nothing to do with opacity; I just made the divs semi-opaque in order to make the issue more visible. Remove the opacity from the jsFiddle mentioned in the initial comment and you'll notice that it doesn't fix the bug. I am also not using preserve3D. That said, the fact that there is another bug like this shows the general "bugginess" of CSS 3D transforms.
See, which cites this bug.

Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.