You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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).
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 applyingbackface: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).
Activity
Gankra commentedon Sep 24, 2018
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 commentedon Sep 25, 2018
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):
The indices were obtained with the help of chasing + capturing infrastructures.
So WR thinks both items are facing the same way, mistakenly.
kvark commentedon Sep 25, 2018
@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 commentedon Sep 26, 2018
I don't think
foo
andfoo::before
are supposed to have a parent-child relationship? ::before is literally before.mstange commentedon Sep 26, 2018
No it's not - it's a really bad name for what it is.
foo::before
is a child offoo
, just before all the other children offoo
.kvark commentedon Sep 26, 2018
I'm inspecting the page and seeing the following hierarchy:

Gankra commentedon Sep 26, 2018
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:
backface: hidden
down to the blue rectbackface:hidden
to the blue rectThe 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 commentedon Sep 26, 2018
(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)
[-]Backface visibility is not propagated properly[/-][+][WIP] Backface visibility is not propagated properly[/+][-][WIP] Backface visibility is not propagated properly[/-][+]Backface visibility is not propagated properly[/+]Auto merge of #3131 - kvark:backface, r=gw3583