Reduce failsafe time for animation events. This makes the lock-time more consistent.

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
Committed: https://crrev.com/aa8ed023a411ac73a2f6e641c902e2831bd1a7fe
Cr-Commit-Position: refs/heads/master@{#383428}

[jdufault, 2016-03-17 21:31:26]

Patchset #1 (id:1) has been deleted

[jdufault, 2016-03-17 22:19:32]

Description was changed from

==========
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
==========

to

==========
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
==========

[jdufault, 2016-03-17 22:19:32]

jdufault@chromium.org changed reviewers:
+ dzhioev@chromium.org

[jdufault, 2016-03-17 22:19:52]

jdufault@chromium.org changed reviewers:
+ xiyuan@chromium.org

[jdufault, 2016-03-17 22:20:16]

Pavel / Xiyuan, PTAL. Thanks!

[xiyuan, 2016-03-18 15:37:49]

https://codereview.chromium.org/1811113003/diff/20001/ui/login/account_picker...
File ui/login/account_picker/user_pod_row.js (right):

https://codereview.chromium.org/1811113003/diff/20001/ui/login/account_picker...
ui/login/account_picker/user_pod_row.js:3250:
ensureTransitionEndEvent(focusedPod);
We need to test |focusedPod| because |focusedPod| is set around line 3254 inside
"if (this.focusedPod_) {" below. If |this.focusedPod_| is not set, we would end
up with a JS error.

Also, for better readability, we should move decl "var focusedPod;" to the
beginning of the function to avoid confusions.

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
File ui/webui/resources/js/util.js (right):

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:381: function ensureTransitionEndEvent(el,
timeOut) {
nit: timeOut -> opt_timeOut and update comments (jsdoc type and name)

i.e.
  @param {number=} opt_timeOut ...

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:382: if (timeOut == null) {
"=== undefined" to test whether an optional arg is passed in,

i.e.
  if (timeOut === undefined) {

[jdufault, 2016-03-18 17:31:56]

https://codereview.chromium.org/1811113003/diff/20001/ui/login/account_picker...
File ui/login/account_picker/user_pod_row.js (right):

https://codereview.chromium.org/1811113003/diff/20001/ui/login/account_picker...
ui/login/account_picker/user_pod_row.js:3250:
ensureTransitionEndEvent(focusedPod);
On 2016/03/18 15:37:48, xiyuan wrote:
> We need to test |focusedPod| because |focusedPod| is set around line 3254
inside
> "if (this.focusedPod_) {" below. If |this.focusedPod_| is not set, we would
end
> up with a JS error.
> 
> Also, for better readability, we should move decl "var focusedPod;" to the
> beginning of the function to avoid confusions.

Done.

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
File ui/webui/resources/js/util.js (right):

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:381: function ensureTransitionEndEvent(el,
timeOut) {
On 2016/03/18 15:37:48, xiyuan wrote:
> nit: timeOut -> opt_timeOut and update comments (jsdoc type and name)
> 
> i.e.
>   @param {number=} opt_timeOut ...

Done.

https://codereview.chromium.org/1811113003/diff/20001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:382: if (timeOut == null) {
On 2016/03/18 15:37:48, xiyuan wrote:
> "=== undefined" to test whether an optional arg is passed in,
> 
> i.e.
>   if (timeOut === undefined) {

Done.

[xiyuan, 2016-03-18 18:23:53]

lgtm

https://codereview.chromium.org/1811113003/diff/40001/ui/webui/resources/js/u...
File ui/webui/resources/js/util.js (right):

https://codereview.chromium.org/1811113003/diff/40001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:377: * @param {number} opt_timeOut The maximum
wait time in milliseconds for the
nit: number -> number=

[dzhioev (left Google), 2016-03-25 22:45:50]

On 2016/03/17 22:20:16, jdufault wrote:
> Pavel / Xiyuan, PTAL. Thanks!

LGTM

[jdufault, 2016-03-25 23:36:48]

The CQ bit was checked by jdufault@chromium.org

[jdufault, 2016-03-25 23:36:48]

The patchset sent to the CQ was uploaded after l-g-t-m from
dzhioev@chromium.org, xiyuan@chromium.org
Link to the patchset: https://codereview.chromium.org/1811113003/#ps60001
(title: "Nit")

[jdufault, 2016-03-25 23:36:56]

https://codereview.chromium.org/1811113003/diff/40001/ui/webui/resources/js/u...
File ui/webui/resources/js/util.js (right):

https://codereview.chromium.org/1811113003/diff/40001/ui/webui/resources/js/u...
ui/webui/resources/js/util.js:377: * @param {number} opt_timeOut The maximum
wait time in milliseconds for the
On 2016/03/18 18:23:52, xiyuan wrote:
> nit: number -> number=

Done.

[commit-bot: I haz the power, 2016-03-25 23:37:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1811113003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1811113003/60001

[commit-bot: I haz the power, 2016-03-26 01:06:07]

Description was changed from

==========
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
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-03-26 01:06:09]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-03-26 01:07:32]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/aa8ed023a411ac73a2f6e641c902e2831bd1a7fe
Cr-Commit-Position: refs/heads/master@{#383428}
==========

[commit-bot: I haz the power, 2016-03-26 01:07:33]

Patchset 3 (id:??) landed as
https://crrev.com/aa8ed023a411ac73a2f6e641c902e2831bd1a7fe
Cr-Commit-Position: refs/heads/master@{#383428}