Possibly related to  bug 767680 ?

What I think happens here is the following:
1. On power button down, power_button_controller calls StartLockThenShutdownAnimation (https://cs.chromium.org/chromium/src/ash/system/power/power_button_controller.cc?rcl=866a0da554ef7718740f3a83c9f0611da26c0275&l=93)
Note that at this point session state is LOGGED_IN_NOT_ACTIVE, which is note reported as blocked.

2. StartLockThenShutdownAnimation calls into LockStateController::StartImmediatePreLockAnimation, which hides lock screen container (i.e. sets its opacity to 0), so it can animate it to shown state, as part of screen lock (https://cs.chromium.org/chromium/src/ash/wm/lock_state_controller.cc?rcl=880af477a8b12b77e871c29cf0ea4e2515fba3d4&l=367)

3. On power button up event, assuming it happens before pre lock animation ends and screen lock is requested, the lock animation is cancelled by calling CancelLockAnimation
(https://cs.chromium.org/chromium/src/ash/system/power/power_button_controller.cc?rcl=514516aea3a1d41f6df0ef5b5bc5f15f7113d081&l=102)

CancelLockAnimation does not undo hide animation on lock containers, so lock containers (including oobe UI) remains invisible.

I can see two (not necessarily not exclusive) ways of fixing this:

* power button controller should not start lock animation if the session is in LOGGED_IN_NOT_ACTIVE state

* CancelLockAnimation should undo ANIMATION_HIDE_IMMEDIATELY animation started on  lock containers container.

#7 explains the reason. Thanks!

I preferred the first way in #8. Actually we probably shouldn't use IsUserSessionBlocked in power_button_controller, instead just checking if session is active. Because it is only dealing with locking screen, not about session restore, window activation, etc. which are described in https://cs.chromium.org/chromium/src/ash/session/session_controller.cc?type=cs&q=isusersessionblocked&l=103

A different approach is used, the post logged in UI flow which is still on the login UI is still considered as part of login session state. Thanks to xiyuan's suggestion: https://chromium-review.googlesource.com/c/chromium/src/+/729748

Question: do we want back porting the fix?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d137301a986a5cfd5cf3025500135774fef09b5

commit 4d137301a986a5cfd5cf3025500135774fef09b5
Author: Qiang Xu <warx@chromium.org>
Date: Fri Oct 20 21:23:02 2017

cros: make post logged in UI flow as part of login

changes:
After user sign in, there might be other session initialization or UI
flow which is still on the same login UI. Make this state part of login
session state.  And make LOGGED_IN_NOT_ACTIVE session state just used
for UserSessionManager::DoBrowserLaunch().

Bug:  772586 
Test: tested on eve for  crbug.com/775286 
Change-Id: Idb244e6970da552ace4bc8e16d8b2cad4ce0d491
Reviewed-on: https://chromium-review.googlesource.com/729748
Commit-Queue: Qiang(Joe) Xu <warx@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510564}
[modify] https://crrev.com/4d137301a986a5cfd5cf3025500135774fef09b5/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/4d137301a986a5cfd5cf3025500135774fef09b5/components/session_manager/session_manager_types.h

Maybe merge to M63. I don't think we should go up to M62 unless this is a RBS.

ok

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/572e4b84370279a9c2de185245533c7757aceabf

commit 572e4b84370279a9c2de185245533c7757aceabf
Author: Qiang Xu <warx@chromium.org>
Date: Sun Oct 22 22:02:41 2017

m63 merge: cros: make post logged in UI flow as part of login

changes:
After user sign in, there might be other session initialization or UI
flow which is still on the same login UI. Make this state part of login
session state.  And make LOGGED_IN_NOT_ACTIVE session state just used
for UserSessionManager::DoBrowserLaunch().

TBR=xiyuan@chromium.org

(cherry picked from commit 4d137301a986a5cfd5cf3025500135774fef09b5)

Bug:  772586 
Test: tested on eve for  crbug.com/775286 
Change-Id: Idb244e6970da552ace4bc8e16d8b2cad4ce0d491
Reviewed-on: https://chromium-review.googlesource.com/729748
Commit-Queue: Qiang(Joe) Xu <warx@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#510564}
Reviewed-on: https://chromium-review.googlesource.com/732616
Reviewed-by: Qiang(Joe) Xu <warx@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#140}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/572e4b84370279a9c2de185245533c7757aceabf/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/572e4b84370279a9c2de185245533c7757aceabf/components/session_manager/session_manager_types.h

10032.29.0, 63.0.3239.37