Created attachment 8813105 [details] A test case Attaching test has a 0.3s opacity animation and a 1s background-color transition. If transition-property is all, the opacity does not get back to the initial value while running the background-color transition. If transition-property is background-color, this bug does not appear at all. Though the opacity value persists after the transition finished, but it will be fixed by bug 1318697. Note that I see this bug on ESR 45.
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
Devtools shows that there is a 1s opacity transition (1.0 -> 0.5)!
Created attachment 8813963 [details] Another test case Setting a new animation whose from value does not equal to the base value triggers a new transition.
Summary: Transition all keeps opacity animation's value while running transition even if the animation finished → Setting a new animation whose from value does not equal to the base value triggers a new transition
There's already at least one spec bug in this area. See bug 1192592.
Thanks! Yes, I think this is somewhat related to bug 1192592. I am reading the spec now. In this case, we compute the base value as startValue and compute the from value of the animation as endValue in nsTransitionManager::ConsiderInitiatingTransition(). What I don't still understand is that setting animation's property (changing keyframes too) is a style change event or not.
IIUC, bug 1192592 is an issue about the before-change style when an CSS animation is removed, whereas this bug is an issue about the after-change style when an CSS animations is added.
See Also: → bug 1192592
You need to log in before you can comment on or make changes to this bug.