cros: Move wallpaper after login screen is gone

ash/session/session_controller.cc

Index: ash/session/session_controller.cc
diff --git a/ash/session/session_controller.cc b/ash/session/session_controller.cc
index 82f5a6c5cf8c11c88a73f778c1082481080a501a..24c01d194f328af19a2c4b63fe44f6b289d59f50 100644
--- a/ash/session/session_controller.cc
+++ b/ash/session/session_controller.cc
@@ -82,13 +82,18 @@ bool SessionController::ShouldLockScreenAutomatically() const {
 }
 
 bool SessionController::IsUserSessionBlocked() const {
-  // User sessions are blocked when session state is not ACTIVE, except that
-  // LOCKED state with a running unlocking animation. This is made an exception
-  // because the unlocking animation hides lock container at the end. During the
-  // unlock animation, IsUserSessionBlocked needs to return unblocked so that
-  // user windows are deemed activatable and ash correctly restore the active
-  // window before locking.
+  // User sessions are blocked when session state is not ACTIVE, with two
+  // exceptions:
+  // - LOGGED_IN_NOT_ACTIVE state. This is needed so that browser windows
+  //   created by session restore (or a default new browser window) is properly
+  //   activated before session state changes to ACTIVE.

[James Cook, 2017/05/24 20:08:13]

Aside: Didn't we have some trouble about 6 months ago with browser windows being
activated in tests? I seem to remember adding and removing a FlushForTesting
call in the session restore code. I wonder if that can be cleaned up (not for
this CL).

[xiyuan, 2017/05/24 20:37:22]

I believe this is the relevant discussion in the CL:

https://codereview.chromium.org/2734933004/diff/100001/chrome/browser/chromeo...

After discussion, FlushForTesting call is not added in the session restore code.
Instead SessionController is changed to have a different default session state
based on whether we have --login-user switch to resolve the issue.

That code could only be removed if we want to make UNKNOWN session state another
exception here. I am not sure whether we want to do that.

[James Cook, 2017/05/24 20:52:35]

Ah, OK. Nothing to do, then.

+  // - LOCKED state with a running unlocking animation. This is needed because
+  //   the unlocking animation hides lock container at the end. During the
+  //   unlock animation, IsUserSessionBlocked needs to return unblocked so that
+  //   user windows are deemed activatable and ash correctly restore the active
+  //   window before locking.
   return state_ != SessionState::ACTIVE &&
+         state_ != SessionState::LOGGED_IN_NOT_ACTIVE &&
          !(state_ == SessionState::LOCKED && is_unlocking_);
 }