gecko-dev/layout/reftests/web-animations
Brian Birtles 4264e3210a Bug 1527210 - Be more consistent about only applying transforms to primary frames; r=hiro
For display:table content we generate two frames: a table wrapper frame and an
inner table frame. The styles are applied to the inner frame (referred to as the
style frame), whilst the wrapper frame is the primary frame for the content.

However, in order to make tables with transforms behave as a container for
abspos/fixed-pos content as required by the spec, we apply the transform to the
wrapper frame (bug 722777) by inheriting the transform from inner to wrapper and
then ignoring the transform on the inner frame (bug 722777 and bug 816458).

When handling animations on table elements we need to be careful of this
distinction. in particular, css animations[1] and web animations[2] require that
when we have an unfinished transform animation targetting an element, the
element acts as if it had `will-change: transform` applied and therefore
generates a stacking context. As a result we need to accurately detect when
a frame should be considered as having transform animations applied to it or not
for the purpose of creating a stacking context.

Previously our handling of display:table content was quite inconsistent and
contradictory. For example, `nsIFrame::HasAnimationOfTransform` would check for
a primary frame AND for animations on that frame, despite the fact that we only
ever store animations on the style frame. As a result it could never return true
for either a table wrapper or inner table frame.

This patch attempts to make this handling at least a little more consistent,
producing the following result:

Outer table frame (primary frame):

    nsIFrame::IsTransformed → true
    nsIFrame::IsCSSTransformed → true
    nsIFrame::HasAnimationOfTransform → true
    nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → false

Inner table frame (style frame):

    nsIFrame::IsTransformed → false
    nsIFrame::IsCSSTransformed → false
    nsIFrame::HasAnimationOfTransform → false
    nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → true

We maintain that the NS_FRAME_MAY_BE_TRANSFORMED bit is only set on the primary
frame whilst the mMayHaveTransformAnimation flag is only set on the style frame.

Note that we don't simply always put everything on the primary frame because for
other property types (e.g. opacity) the default setup of putting all styles and
animations on the style frame is simpler and correct. So far it is only
transforms that require special handling to apply the effect to the wrapper
frame.

This patch adds a reftest that fails without the code changes included in this
patch.


[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section

Differential Revision: https://phabricator.services.mozilla.com/D21883

--HG--
extra : moz-landing-system : lando
2019-03-05 03:09:19 +00:00
..
1246046-1.html
1267937-1.html
1267937-ref.html
1298742-1.html
1298742-ref.html
1363639-1.html
animation-utils.js
cancel-animation-with-selector-matching.html
child-in-animating-element-display-none-ref.html
child-in-animating-element-display-none.html
green-box.html
reftest.list Bug 1527210 - Be more consistent about only applying transforms to primary frames; r=hiro 2019-03-05 03:09:19 +00:00
restyle-after-display-none.html
stacking-context-animation-changing-target-ref.html
stacking-context-animation-on-table-ref.html Bug 1527210 - Be more consistent about only applying transforms to primary frames; r=hiro 2019-03-05 03:09:19 +00:00
stacking-context-animation-ref.html
stacking-context-opacity-changing-effect.html
stacking-context-opacity-changing-keyframe-in-delay.html
stacking-context-opacity-changing-keyframe.html
stacking-context-opacity-changing-target-in-delay.html
stacking-context-opacity-changing-target.html
stacking-context-opacity-losing-css-animation-in-delay.html
stacking-context-transform-changing-display-property.html
stacking-context-transform-changing-effect-on-table.html Bug 1527210 - Be more consistent about only applying transforms to primary frames; r=hiro 2019-03-05 03:09:19 +00:00
stacking-context-transform-changing-effect.html
stacking-context-transform-changing-keyframe-in-delay.html
stacking-context-transform-changing-keyframe.html
stacking-context-transform-changing-target-in-delay.html
stacking-context-transform-changing-target.html
stacking-context-transform-losing-css-animation-in-delay.html
stacking-context-transform-none-animation-before-appending-element.html
style-updates-for-iteration-composite-ref.html
style-updates-on-current-iteration-changed.html
style-updates-on-iteration-composition-changed-from-accumulate-to-replace.html
style-updates-on-iteration-composition-changed-from-replace-to-accumulate.html