The WPT reftest css/css-transforms/transform3d-backface-visibility-005.html is failing.

Test case: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/transform3d-backface-visibility-005.html

Reftest analyzer view: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/SsHso2dKRbCup-k22gpffg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=0ec8e6c560cd86f7d0d19d41cede6014fe9dd546

It's currently marked FAIL for all of the QR platforms at https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/testing/web-platform/meta/css/css-transforms/transform3d-backface-visibility-005.html.ini

This one is interesting, we have the exact opposite Wrench test ("reftests/backface/backface-leaf.yaml"), so we don't have the fully correct model, it seems, and it needs to be conceptually refined.

Matt, can you figure out what the correct behaviour here should be?

I think that the wrench test is just wrong here.

The spec is really unclear on this stuff, and the current gecko behaviour is weird (but the closest to a literal interpretation of the spec), but it seems that blink, WebKit and gecko all agree on the WPT test being valid in this case.

The interpretation is that backface-visibility is computed using the transform to the root of the current '3d rendering context'.

The element with backface-visibility isn't transformed, and thus is it's own '3d rendering context' with the identity transform, and so we're viewing the front face of it (relative to the parent).

Adding preserve-3d on the transformed parent would mean that the '3d rendering context' created by the transformed parent would then extend to include its children, and then we'd consider that rotation when deciding which face is visible.

Thanks Matt!

I looked at our implementation once more, trying to come up with a quick fix. I think the fix isn't going to be as quick:

• current logic of get_relative_transform just returns VisibleFace enum, and it does multiple flattening operations in general
• we only compare this with the backface visibility property at the end

Instead, we should be comparing the backface visibility at each flattening moment, and break at first place where we know the element is invisible (and cache it per stacking context, of course).

Looking at this more after the break. So the new rules, translated to WR language would be the following:

If a primitive or a picture is in preserve-3d hierarchy, then we compute the transform to the containing block coordinate space (which is not flattened at any point), and this defines our visibility of the backface.

If a picture is not in preserve-3d, we compute its backface visibility based on the transform of the relevant stacking context.

For primitives outside of preserve-3D hierarchy, the backface-visibility should be ignored (!). Justification: if the respective DOM element is transformed, we evaluate the visibility at the picture level corresponding to that transformed stacking context. If flat and not transformed, then it's always front face visible.

Converting this to actionable items: we need slightly separate code paths for backface-visibility evaluation on picture versus primitive (or rather, primitive cluster) level.

This changes our backface visibility semantics to a slightly more complex rule,
as described by Matt (and reinterpret by me in the context of WR) in bug 1525641 during our work week.
We are now propagating is_backface_visible to pictures and evaluate it in the context of
the local transform for a picture if it's outside of preserve-3d context.
We also refactor get_relative_transform() a bit.

Note: this fixes all of the existing backface-visibility bugs: 1525641, 1546110, 1546818
It also passes the Wrench tests, but the try push is still pending for surprises.

https://hg.mozilla.org/mozilla-central/rev/4521516e7c46