Open Bug 1201471 Opened 4 years ago Updated Last year
backface-visibility:hidden ignored on untransformed element that is child of preserve-3d element
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36 Steps to reproduce: FireFox shows the backface in spite of `backface-visibility:hidden` being set on both the front and back elements on a standard 'flip card' animation. See http://stackoverflow.com/questions/9604982 The solution is to put `backface-visibility:hidden` both on the object and its container. However, adding this to the container makes the back unresponsive in Chrome. This bug is present in FireFox version 40.0.3.
Could you attach a simple testcase showing up the issue, please.
Hi, Here is a fiddle: https://jsfiddle.net/bfzcd7ka/2/ As can be seen, the backface text "Front" is visible in spite of `backface-visibility: hidden;` being set on both `.front` and `.back`. Try the same fiddle on Chrome or Edge and it works correctly. Uncomment the FireFox specific styling right at the top to get it working on FireFox 40.0.3. It should not be necessary to have to add `backface-visibility: hidden;` to the parent element. Furthermore, adding this causes another problem on Chrome, where the backface becomes unresponsive. Noel
Could you attach a screenshot from Edge or Chrome, please. I'm not sure IE11 on my machine is displaying the right rendering.
Adding screenshot from Chrome 44.0.2403.157
Just as an aside: "I don't have access to another browser" is rather a poor excuse. This is the first bug I've reported and honestly it shouldn't be so much work. Please consider moving this whole operation to GitHub where things are more transparent.
Testcase from https://fiddle.jshell.net/bfzcd7ka/2/show/ , with some extra jsFiddle gunk removed. Attaching so that we can discuss the testcase without the risk of it changing or disappearing, and also without the jsfiddle gunk so that we know that the CSS present is just what we see in view-source and not the misleading view that jsFiddle shows (since it adds an extra style sheet).
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a98a1d78817f&tochange=58eca03214a6 Matt Woodrow — Bug 968555 - Don't create a stacking context for backface-visibility:hidden. r=dbaron
Version: 40 Branch → 30 Branch
I think our behavior matches the current spec, although I admit that the spec is very hard to follow. The problem is that the element with class="front" has no transform, which I believe means it does not participate in the 3D rendering context as described in https://drafts.csswg.org/css-transforms/#transformed-element-hierarchies . This, in turn, means that backface-visibility shouldn't do anything. That said, I think the spec is a mess and it's clear neither than this is actually what the spec says nor that it's what the spec means to say. Adding 'transform: rotateX(0deg)' to the .front, .back rule fixes this.
No longer blocks: 968555
Summary: backface-visibility:hidden not being honoured → backface-visibility:hidden ignored on untransformed element that is child of preserve-3d element
Version: 30 Branch → 40 Branch
Please fix this bug! It still persist in Firefox 50.0 :(
Component: Layout: View Rendering → Layout: Web Painting
Can you please update this link. I would like to look into this issue more but need a starting point: https://drafts.csswg.org/css-transforms/#transformed-element-hierarchies The hash no longer points to a section of the document.
You need to log in before you can comment on or make changes to this bug.