1201471 - backface-visibility:hidden ignored on untransformed element that is child of preserve-3d element

Status: UNCONFIRMED

(Core :: Web Painting, defect)

Description

[noel.abrahams]

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.

Comment 1

[Loic]

Could you attach a simple testcase showing up the issue, please.

Comment 2

[noel.abrahams]

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

Comment 3

[Loic]

Could you attach a screenshot from Edge or Chrome, please. I'm not sure IE11 on my machine is displaying the right rendering.

Comment 4

[noel.abrahams]

Attachment: Chrome.png

Adding screenshot from Chrome 44.0.2403.157

Comment 5

[noel.abrahams]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reporter's testcase

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).

Comment 7

[Loic]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0056.html

Comment 10

[gloofer]

Please fix this bug! It still persist in Firefox 50.0 :(

Comment 11

[john.morsey.007]

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.