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)

enhancement

Tracking

()

People

(Reporter: hiro, Unassigned)

Details

Attachments

(1 file)

Attached file test.html (deleted) —
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.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: