Call AnimationProgressed when MultiAnimation finishes
When gfx::MultiAnimation exceeds its cycle time and isn't running continuously, it calls Stop(), but doesn't first call AnimationProgressed(). This means that the final animation state might not be reached, i.e. AnimationProgressed() is not guaranteed to run with a current value of 1.0. I've fixed that quirk in this CL by calling AnimationProgressed() before stopping the animation. This allows me to delete some code that was hacking around this quirk in the omnibox simplified domain field trial implementation. OmniboxViewViews::ElideAnimation was forcing the final frame to run by calling AnimationProgressed() from AnimationEnded(). This hack was causing a DCHECK failure when the simplified domain elision animation was cancelled after the underlying RenderText text contents changed. In other words, because ElideAnimation::Stop() really meant "run the final frame and then stop", there was no safe way to cancel the animation when its state had become stale. Now, with this MultiAnimation fix, MultiAnimation ensures that the final frame runs before the animation finishes, and ElideAnimation::Stop() just stops the animation without running any frames. Bug: 1103738 Change-Id: Idbf55bc2f326d3eaa9bf97a288e3ab467097953e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2330613 Commit-Queue: Emily Stark <estark@chromium.org> Reviewed-by:Robert Flack <flackr@chromium.org> Reviewed-by:
Tommy Li <tommycli@chromium.org> Cr-Commit-Position: refs/heads/master@{#795209}
Showing
Please register or sign in to comment