cros: Only preload the lock screen; do not reuse it.

chrome/browser/resources/chromeos/login/lock.js

Index: chrome/browser/resources/chromeos/login/lock.js
diff --git a/chrome/browser/resources/chromeos/login/lock.js b/chrome/browser/resources/chromeos/login/lock.js
index 4028f54f2e6b65971008ee0a923a853a95debd16..d71245e64d4117e1b0e77aef22972e71557b61fe 100644
--- a/chrome/browser/resources/chromeos/login/lock.js
+++ b/chrome/browser/resources/chromeos/login/lock.js
@@ -74,31 +74,6 @@ cr.define('cr.ui.Oobe', function() {
       showPinKeyboardAsync();
     },
 
-    /**
-     * Called when a preloaded webview (this) instance is being reused to
-     * display a new lock screen session. This will also be called when a
-     * lock screen has been preloaded and is being displayed for the first
-     * time.
-     */
-    reload: function() {
-      // Sending accountPickerReady displays the webui. Wait for the next
-      // animation frame so the user does not see any state from the previous
-      // instance.
-      requestAnimationFrame(function() {
-        chrome.send('accountPickerReady');

[xiyuan, 2017/01/06 17:14:25]

Would we lost this signal? This signal triggers ScreenLocker::ScreenLockReady
that notifies session manager and sets session state.

How would it work in preloaded case?

[jdufault, 2017/01/13 19:46:58]

Loading the webui doesn't actually initialize of the session specific data. I
believe before this was only needed if the webui had already been displayed once
before. So this change should be ok.

Tracing through everything, this normally gets sent via

  JS ScreenAccountPicker.onShow
  ...
  JS UserPodRow.handleAfterShow
  ...
  JS Oobe.showScreen {"data":{"disableAddUser":false},"id":"account-picker"}
  #1 chromeos::BaseScreenHandler::ShowScreenWithData()
  #2 chromeos::SigninScreenHandler::ShowImpl()
  #3 chromeos::SigninScreenHandler::Show()
  #4 chromeos::OobeUI::ShowSigninScreen()
  #5 chromeos::WebUIScreenLocker::LockScreen()
  #6 chromeos::ScreenLocker::Init()
  #7 chromeos::ScreenLocker::Show()
  #8 chromeos::ScreenLocker::HandleLockScreenRequest()

I'm guessing that one of those functions is doing caching and not calling the
rest of the sequence if the screen is already set to 'account-picker'.

[xiyuan, 2017/01/13 20:14:18]

Acknowledged.

-      });
-    },
-
-    /**
-     * Called when the lock screen has been dismissed but this webview will stay
-     * in memory. The webview will be reused when Oobe.reload() is called.
-     */
-    teardown: function() {
-      // The PIN keyboard will disable the virtual keyboard. Make sure to
-      // revert the force disable when hiding the lock screen.
-      chrome.send('setForceDisableVirtualKeyboard', [false]);
-    },
-
     // Dummy Oobe functions not present with stripped login UI.
     initializeA11yMenu: function(e) {},
     handleAccessibilityLinkClick: function(e) {},