1362543 - Child elements of preserve-3d contexts are rendered differently from Chromium

Status: RESOLVED FIXED

(Core :: Layout, enhancement, P3)

Description

[Dzmitry Malyshau [:kvark]]

Default transform style of an element is "flat". When this element does not establish a stacking context, but it's parent is a "preserve3d" stacking context, the rendering of children elements is different between Firefox and Chromium.

https://github.com/servo/servo/blob/master/tests/wpt/css-tests/css-transforms-1_dev/html/transform-table-006.htm
https://github.com/servo/servo/blob/master/tests/wpt/css-tests/css-transforms-1_dev/html/transform3d-sorting-004.htm

Firefox (both 52 and nightly) doesn't plane split and re-order the inner transformed elements, while Chromium apparently considers the implicit change of "transform-style" a reason to spawn a stacking context (or at least behave as if it's re-established). Basic test case:

  <div style="transform-style: preserve-3d">
    <div><!-- This is where the transform-style changes to Flat -->
      <div style="transform: .."></div>
      <div style="transform: .."></div>
    </div>
  </div>

We should figure out the correct way of rendering/laying out this case, and fix the code/specification accordingly.

Comment 1

[Matt Woodrow (:mattwoodrow)]

I think this is our bug.

The TR spec says "An element participates in a 3D rendering context if its containing block establishes or extends a 3D rendering context."

We're using the parent frame to determine if we're participating in a 3D rendering context, not the nearest containing block ancestor.

The latest draft changes everything again, but I don't think anyone actually implements that.

Comment 2

[Dzmitry Malyshau [:kvark]]

See also: https://github.com/w3c/web-platform-tests/issues/5931

Comment 3

[Matt Woodrow (:mattwoodrow)]

A more difficult example is: 

<div style="transform-style: preserve-3d">
    <div style="opacity:0.5">
      <div style="transform: .."></div>
      <div style="transform: .."></div>
    </div>
</div>

The spec says that opacity overrides transform-style to be treated as if it were 'flat', but the div with opacity doesn't even have transform-style at all.

We really do want to flatten in this case, so we need to look at the opacity somehow.

The latest draft spec resolves this by introducing a third value for transform-style, 'auto', that is the default and extends any existing preserve-3d contexts. Any property that causes flattening (like opacity) changes the default for that element to be 'flat' instead of 'auto'.

I don't think anybody implements that currently though, but I've had trouble in the past getting changes made to the TR spec (since the ED is the only one the authors care about).

Comment 4

[Matt Woodrow (:mattwoodrow)]

I just added a patch to bug 1359709 which changes our behaviour to be even closer to using the direct parent (previously we used the containing block if the transformed frame was also abs/fixed pos).

I suspect we want to walk up the frame/DOM tree, until we find anything that flattens preserve-3d (and return false), or find a containing block (and return true if it has preserve-3d).

Comment 5

[Dennis Schubert [:denschub]]

The two WPTs linked in comment 0 now pass in Firefox, so I assume this is fixed.