diff options
author | jdufault <jdufault@chromium.org> | 2016-03-25 18:05:57 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2016-03-26 01:07:27 +0000 |
commit | aa8ed023a411ac73a2f6e641c902e2831bd1a7fe (patch) | |
tree | 18a48f2c0994a209818884cd043ae0f7036cbd35 /sync/sessions/status_controller.h | |
parent | eb6813df8a49dbe1e9afa3994f1347ec6329340f (diff) | |
download | chromium_src-aa8ed023a411ac73a2f6e641c902e2831bd1a7fe.zip chromium_src-aa8ed023a411ac73a2f6e641c902e2831bd1a7fe.tar.gz chromium_src-aa8ed023a411ac73a2f6e641c902e2831bd1a7fe.tar.bz2 |
Reduce failsafe time for animation events. This makes the lock-time more consistent.
This animation delay compensates for the amount of time it takes the native
animation to run so the user pods are not shown while the native windows are
flying out of the screen. This approach has a few problems, however:
1. If the WebUI takes a long time to load (such as on slow devices), then the
CSS animation here will still be running even after the native animation
has completed.
2. If the screen is locked via some cancellable lock mechanism, such as the
power button, then the native animation has already completed and the wait is
unnecessary.
A better approach is to intead have the lock screen emit an event that notifies
the webui that has finished the native animation. Doing so is tricky, however,
as there are various states that the webui and lock screen can be in.
BUG=452599
Review URL: https://codereview.chromium.org/1811113003
Cr-Commit-Position: refs/heads/master@{#383428}
Diffstat (limited to 'sync/sessions/status_controller.h')
0 files changed, 0 insertions, 0 deletions