Setting a new animation whose from value does not equal to the base value triggers a new transition

NEW
Unassigned

Status

()

P3
normal
2 years ago
a year ago

People

(Reporter: hiro, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox50 affected, firefox51 affected, firefox52 affected, firefox53 affected)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
(Reporter)

Updated

2 years ago
Flags: needinfo?(hiikezoe)
(Reporter)

Comment 1

2 years ago
Devtools shows that there is a 1s opacity transition (1.0 -> 0.5)!
Flags: needinfo?(hiikezoe)
(Reporter)

Comment 2

2 years ago
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.
(Reporter)

Updated

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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.
(Reporter)

Comment 5

2 years ago
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.