GitLab

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}