Webrender: Backface visibility is not propagated properly

[kvark]

This is a WR tracking bug for the following Gecko issues:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1492030
• https://bugzilla.mozilla.org/show_bug.cgi?id=1454706

[Gankra]

test-case demonstrating this is both Z-fighting and one element (the .back::before psuedo-element's background) getting which side its "back" is backwards. backface-visibility seems to be propagating properly, afaict.

https://bugzilla.mozilla.org/show_bug.cgi?id=1454706#c14

[kvark]

Thanks for the test case @Gankro !

I'm observing the world transformations for both red and blue planes to be the same, which is unexpected (given that one is supposed to be flipped):

// spatial node index 12
[1.0252677, 0.029520191, -0.17364818, 0.0001736482, 0.0, 1.0, 0.0, 0.0, -0.05581203, -0.16741732, 0.9848077, -0.0009848077, 156.10492, 86.78599, 13.023613, 0.9869764]
// spatial node index 15
[1.0252677, 0.029520191, -0.17364818, 0.0001736482, 0.0, 1.0, 0.0, 0.0, -0.05581203, -0.16741732, 0.9848077, -0.0009848077, 186.86295, 87.6716, 7.814169, 0.99218583]

The indices were obtained with the help of chasing + capturing infrastructures.

So WR thinks both items are facing the same way, mistakenly.

[kvark]

@Gankro the title needs to be changed, but I've yet to find what to change it to ;)

I actually got confused about that testcase now. .back::before ends up with the same world transformation (as the red rectangle) appears to be expected by the testcase, since it's flipped but the parent (with class "bf-invisible container-inner back") is also flipped. So I'm not sure what the desired outcome should be.

Do you think that it should function as if the parent establishes the stacking context, and since it has the backface visibility disabled, all children should be invisible if the spatial node (corresponding to this context, not the children) is turning the back? This is obviously different from the current logic, where we just propagate the flag and check for backface visibility at the primitive level (as opposed to the stacking context level).

[Gankra]

I don't think foo and foo::before are supposed to have a parent-child relationship? ::before is literally before.

[mstange]

No it's not - it's a really bad name for what it is. foo::before is a child of foo, just before all the other children of foo.

[kvark]

I'm inspecting the page and seeing the following hierarchy:

[Gankra]

Ok after some discussion with mstange and some experimentation with gecko/chrome, it looks like this is incorrect backface-visibility handling. The blue is indeed double rotated, and therefore facing the same way as the red.

The mistake is one of two things, which we still need to work out:

• we're incorrectly propagating backface: hidden down to the blue rect
• we're incorrectly applying backface:hidden to the blue rect

The distinction being whether the blue rect should be considered rotated and actually rendered in 3d, or just rotated and 2d-projected into its parent. In the latter case the blue rect's backface doesn't actually matter, but rather only the backface of the parent does. My hypothesis is that the latter is occuring, because otherwise the blue rect would be "always visible" and would therefore always draw on top of the red one (as it does in the backface:visible example).

[Gankra]

(note the red and blue rects are slightly different because the blue rect has a transform directly applied to it, and the red one doesn't)