Open
Bug 1460804
Opened 6 years ago
Updated 2 years ago
Compositor animations having positive delay and end delay persist on the compositor even if they are not in-effect any more
Categories
(Core :: DOM: Animation, enhancement, P3)
Core
DOM: Animation
Tracking
()
NEW
People
(Reporter: hiro, Unassigned)
Details
Attachments
(1 file)
619 bytes,
text/html
|
Details |
Attaching file has an opacity animation having 500ms delay and very long end delay. And the opacity animation is 'opacity: 1 -> 1', and the target element has 'opacity: 0' property.
Once the animation reaches to the end of its duration, the target element should disappear (i.e. painted by opacity:0), but actually the element stays there without forcibly flushes (e.g. moving mouse, etc.).
The cause is that we do send the opacity animation in-delay phase, that means that mProgressOnLastCompose keep being null, thus, HasComputedTimingChanged() always returns true unfortunately. If the animation had 0 delay, mProgressOnLastCompose isn't null then HasComputedTimingChanged() returns false, then CanThrottle() is called and then it returns false when the animation reached to the end of the duration since IsInEffect() check is in CanThrottle().
Moving HasComputedTimingChanged() check after `!IsInEffect() || !IsCurrent()` check in CanThrottle() should fix this issue. That's said, I am not sure this is the right thing to do, given that positive end delay might be useful to avoid filckering of frame based animation.
Reporter | ||
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•