1031688 - strange interpolation and computed value rules for 'transform' lead to phantom transitions and other strange behavior

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In bug 996796 I'm adding some mochitests to test_animations_omta_start.html that have to be todo_is because of a bug related to inheritance.  (At this point I've forgotten the details of that bug; I should have filed this bug more quickly after writing the test.)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I believe this is a combination of three issues:

 (1) something I don't understand yet that's letting a style change triggered by the start of an animation be considered when starting a transform

 (2) the fact that there are values of transform whose presence in a keyframe at 0% (i.e., 100% of the current interpolation, but running through the interpolation code) leads to a different computed value than the value, in the sense that the values are different enough to start a transition.  In particular, translateX(0) interpolated with some other translateX() value at 0% of the way yields translate3d(0, 0, 0), which is different enough from translateX(0) that we start a transition between the two.  (I believe this is what the spec requires, which I think is horrible!)

 (3) issues managing what animation data is on the layer when there's both a transition and animation running on the element.  (I have a patch in my tree that might improve this, although I'm not sure if it fixes the case of what happens when one of them ends.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

s/starting a transform/starting a transition/

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #1)
>  (1) something I don't understand yet that's letting a style change
> triggered by the start of an animation be considered when starting a
> transition

Actually, what seems to be happening is that we have the animation already started, and then we do (all inside the first AdvanceTimeAndRefresh(0) call) a restyle *without* animation, which has the old style context including the inherited CSS animation style, but the new style context inherits the 'transform: translateX(0)' instead of the interpolated value.  This is the sort of thing that should be fixed by the new approach to transitions.

Comment 4

[Brian Birtles (:birtles)]

I don't know what specific error you're seeing in the test in test_animations_omta_start.html, but one gotcha I've sometimes encountered with transform animations on the compositor is that sometimes when the first frame of the animation lines up with style already applied by a backwards-fill for example, RestyleManager::ComputeStyleChangeFor (actually ElementRestyler::CaptureChange) filters out the redundant change and we don't send the animation to the compositor until the first frame where the transform value differs.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So I'm going to switch the test to opacity to avoid this bug, though it it still hits bug 1039799, which is part of what I was seeing.