Make WPT css/css-transforms/transform3d-backface-visibility-005.html pass on windows

RESOLVED FIXED in Firefox 68

Status

()

defect
P2
normal
RESOLVED FIXED
6 months ago
3 months ago

People

(Reporter: kats, Assigned: kvark)

Tracking

(Blocks 1 bug)

Other Branch
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

Assignee: nobody → dmalyshau
Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P3
Priority: P3 → P2

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.

Assignee: dmalyshau → matt.woodrow

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

Flags: needinfo?(matt.woodrow)

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.

Flags: needinfo?(matt.woodrow)

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

Assignee: matt.woodrow → dmalyshau
Status: NEW → ASSIGNED

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.

See Also: → 1546818

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.

Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4521516e7c46
Revise WR backface visibility semantics, separate picture and primitive logic r=gw
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Duplicate of this bug: 1546110
Duplicate of this bug: 1546818
You need to log in before you can comment on or make changes to this bug.