Add a very basic PIN UI implementation that is shared between lock and settings.

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

Index: chrome/browser/resources/chromeos/login/custom_elements_lock.js
diff --git a/chrome/browser/resources/chromeos/login/custom_elements_lock.js b/chrome/browser/resources/chromeos/login/custom_elements_lock.js
index 6853db73b68936cd3ee35d8b0ac4811bd738f192..c6eec8b339b47dfe0e9ace897cc39f6148e829e8 100644
--- a/chrome/browser/resources/chromeos/login/custom_elements_lock.js
+++ b/chrome/browser/resources/chromeos/login/custom_elements_lock.js
@@ -1,3 +1,42 @@
 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
+
+(function() {
+  'use strict';
+
+  // How long until we wait for an idle event before forcibly loading the PIN
+  // HTML.
+  /** @const */ var PIN_IDLE_TIMEOUT_MS = 250;
+
+  let onPinLoaded = function() {
+    let pinContainer = $('pin-container');
+    pinContainer.style.opacity = 1;
+  };
+
+  // We only want to load the PIN HTML if we are actually showing it. The PIN
+  // element pulls in polymer with paper elements and can take a significant
+  // amount of time to load. If the user does not have a PIN unlock, we can skip
+  // loading all of the PIN-related code.
+  //
+  // TODO(jdufault): If we don't have pods, we don't need to worry about the
+  // intro-animation, and we can load directly in DOMContentLoaded.
+  //
+  // Directly loading the element in DOMContentLoaded or load results in the
+  // pod intro animation getting interrupted. Loading it in an idle callback
+  // defers the load enough that the animation does not get interrupted.
+  let showPin = loadTimeData.getBoolean('showPin');
+  if (showPin) {
+    window.addEventListener('DOMContentLoaded', function() {

[tommycli, 2016/05/02 16:11:26]

Can we commit the "naive" and obvious approach for the first pass and then
address performance concerns after?

[jdufault, 2016/05/03 19:21:57]

We can't load this directly from the HTML file, because then it will be loaded
when we are not using PIN unlock. We try to keep lock screen initialization time
at a bare minimum.

So it ends up that the there isn't an obvious approach (that I know of - any
ideas?); I think the simplest we can do is to remove the requestIdleCallback
invocation. I don't think having that adds much complexity, so I'd prefer to
leave this as-is for now.

[tommycli, 2016/05/04 19:29:02]

Hmm, this still seems pretty non-obvious. Can we load it directly in the HTML
file and use Polymer's lazy registration to reduce the performance cost?
https://www.polymer-project.org/1.0/docs/release-notes.html#v1-4-0

Or alternatively, if you really don't want to pay the cost, maybe load it in an
IFRAME dynamically?

[jdufault, 2016/05/06 00:05:46]

I did some investigation here.

Using polymer lazy registration is still too-heavy performance wise - loading
times goes from 1.3s to 2s, which is a big regression. Even with lazy
registration, the PIN element will still have to be inserted into the DOM
dynamically otherwise the lazy loading will not work.

An iframe approach is promising, but it introduces a fairly large amount of
spread-out complexity:
- It requires adding some new files, pin_host.html/css/js.
- The iframe needs to be conditionally loaded otherwise the PIN will always show
up, which means we still need some (simpler) JS in this file - we might be able
to work around this in oobe_ui.cc by just not exposing the pin_host.html file.
- It requires a CSP whitelist in oobe_ui.cc.
- It is styled separately from everything else. The primary problem here is
width/height of the PIN element.
- pin_host.js has to install a 'submit' event listener on the pin element and
forward the event to the parent document.

I prefer the current approach simply because it has so much less complexity -
for example, I have a feeling that tabbing will require workarounds if we go
with the iframe approach.

I reworked the current approach a little; hopefully it reads better.

Depending on timing and how everything feels at the end of this project, I may
do further investigation on using an iframe for performance reasons, as we can
start loading the PIN keypad immediately which may make it show up a bit sooner,
but it increases the lock-load time from 1.3s to 1.5s.

[xiyuan, 2016/05/06 16:52:34]

I wonder whether we could use existing cr.ui.login.ResourceLoader (xhr based)
for the async loading. Currently, the enrollment screen is loaded via that [1].
This might add more work as we might need to change how pin html/js/css a bit
and extend ResourceLoader.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/res...

[jdufault, 2016/05/06 23:44:17]

Done - moving the resource loading code to ResourceLoader makes this code much
easier to read.

+      let loadPin = function() {
+        let link = document.createElement('link');
+        link.rel = 'import';
+        link.href = 'chrome://oobe/custom_elements/pin.html';
+        link.onload = onPinLoaded;
+        document.head.appendChild(link);
+      };
+
+      window.requestIdleCallback(loadPin, { timeout: PIN_IDLE_TIMEOUT_MS });
+    });
+  }
+})();