MD Settings: Users: Fix add person validation and dialog focus

chrome/browser/resources/settings/people_page/users_page.html

Index: chrome/browser/resources/settings/people_page/users_page.html
diff --git a/chrome/browser/resources/settings/people_page/users_page.html b/chrome/browser/resources/settings/people_page/users_page.html
index 6a542f2996f36ca2b9a90c2552e6558bf84365f6..a6576e12f1668813a148f9dc47415e5226462170 100644
--- a/chrome/browser/resources/settings/people_page/users_page.html
+++ b/chrome/browser/resources/settings/people_page/users_page.html
@@ -70,7 +70,8 @@
         </div>
       </div>
     </div>
-    <settings-users-add-user-dialog id="addUserDialog">
+    <settings-users-add-user-dialog id="addUserDialog"

[dpapad, 2017/04/10 17:39:39]

Just FYI, as an alternative to clearing the dialog's state in open(), you could
also use a  <template is="dom-if" restamp> around the dialog to ensure that no
information is leaking between dialog invocations. Then you would not have to
worry about resetting any state, which might be a bit more robust and better for
performance anyway (why render a settings-users-add-user-dialog even in cases
when it will not be shown to the user)?

[stevenjb, 2017/04/10 22:02:01]

The problem with that technique is that it requires using async to open the
dialog after setting the comtrol property, which is fine and all but a bit more
code to maintain.

Also, I personally prefer using data binding anyway rather than relying on
explicitly setting the disabled state; it makes it clear when inspecting the
HTML that the control may be enabled/disabled.

[tommycli, 2017/04/10 22:18:09]

Hey, the pattern dpapad used elsewhere is to put the "showModal" call in the
attached lifecycle call:
https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/clear_...

I actually do agree with dpapad that having "auto-open" dialogs that are
restamped is the cleanest solution. (And I have tried about 3 other variants)

[stevenjb, 2017/04/10 22:43:59]

That example is a little odd, there we have a route to the dialog and show it in
currentRouteChanged:
https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/privac...

Does the same pattern work with just setting 'showFoo_ = true' anywhere? Do we
have good examples of that?

I'd prefer to get this in and re-factor it later, but it's a P2 so if we have to
merge after the branch that's not a big deal either (I'm deep in Internet
settings right now).

[dpapad, 2017/04/11 00:03:55]

Yes, here is another example, for a dialog that does not have a route,
https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/on_sta....
Most of our dialogs actually use this pattern (boolean + restamp + calling
showModal() inside attached()).
That's fine by me.

+        on-close="onAddUserDialogClose_">
     </settings-users-add-user-dialog>
   </template>
   <script src="users_page.js"></script>