commit d09f574166a85c8b1d85fd1d05a974e4866e18a8
author Ryan Hansberry <hansberry@chromium.org> Wed Jan 26 19:33:45 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Jan 26 19:33:45 2022
tree 34d6d7d62ee65495910dcae34b48ba7528261bc1
parent a408632c0a4786cd8e72a4e3847fd56e64240db6

[SmartLock] Re-show password field when leaving kAuthenticated state.

When Smart Lock is the active auth factor, do not associate just
state==kClickRequired to "hide password field"; also associate hiding
the password field to state==kAuthenticated.

Now, unconditionally set a "hide password" field on
LoginAuthFactorsView each time the state changes to kClickRequired or
kAuthenticated (or neither), and expose it via a method for
LoginAuthUserView to consume (removing the previous unnecessary
callback mechanism).

Explanation:

Bug b:214051215 occurs when Sign-in with Smart Lock seems to be
working up to the last second (state==kAuthenticated and the green
check mark is shown), but Cryptohome returns a failure shortly
afterward (state becomes kErrorForeground).

In this unique state change, the password field is not reshown,
because hiding the password field is (supposedly) only supposed to
happen upon entering or leaving state==kClickRequired. In reality,
the existing code is *actually* hiding the LoginAuthUserView password
field based on whether the new state was kClickRequired
*OR kAuthenticated*. But because this association isn't explicit,
the existing code does not consider leaving the kAuthenticated state
to be a reason to re-show the password -- the password field remains
stuck/hidden.

Fixed: b:214051215
Change-Id: Ia0423b71e582d3642e51bbaa2f2b55fa53496917
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3405569
Reviewed-by: Thomas Tellier <tellier@google.com>
Reviewed-by: Curt Clemens <cclem@google.com>
Commit-Queue: Ryan Hansberry <hansberry@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963639}