web: Indicate when caps-lock is active during password input. (#12733)
Determining the state of the caps-lock key can be tricky as we're
dependant on a user-provided input to set a value. Thus, our initial
state defaults to not display any warning until the first keystroke.
- Revise to better use lit-html.
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* web: fix esbuild issue with style sheets
Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).
Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.
In standard mode, the following warning appears on the console when running a Flow:
```
Autofocus processing was blocked because a document already has a focused element.
```
In compatibility mode, the following **error** appears on the console when running a Flow:
```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
at initDomMutationObservers (crawler-inject.js:1106:18)
at crawler-inject.js:1114:24
at Array.forEach (<anonymous>)
at initDomMutationObservers (crawler-inject.js:1114:10)
at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```
Despite this error, nothing seems to be broken and flows work as anticipated.
* web: provide `show password` on login page
Provide a `show password` icon, text, and button for the password field both in the
IdentificationStage and the PasswordStage. Essentially the same code for both, although the id of
the password field is unique to each.
Requested by Cloudflare. Seems to be a common thing anyway.
Should it be an administrative option that this facility is available? From where should I derive
that information? I suspect the answer is "a site attribute," but I'd like to get confirmation.
* web: comment doesn't need to be exposed. It's sufficient where it is .
* web: fix button rendering issues
During testing, the buttons did not change as expected. We are using pure DOM
state to control the look of the button, and avoiding using `.requestUpdate()`
to avoid losing customer input, so depending upon Lit to re-render just the
button was an error.
This commit goes old-school and updates the button's label and icon using
standard DOM features, although we do lean into Lit-html`s `render()`
function to create the DOM component for the icon.
* web: provide `show password` on login page
Provide a `show password` icon, text, and button for the password field both in the
IdentificationStage and the PasswordStage. Essentially the same code for both, although the id of
the password field is unique to each.
Provide a configuration detail server-side to allow administrator to enable or disable the 'show
password' feature. Off by default.
Requested by Cloudflare. Seems to be a common thing anyway. Making it configurable wasn't in
Cloudfare's request, but it seemed logical to add.
* ensure the tests pass; quibbling over the wording of the admin field continues.
* Removed some manually identified fluff.
* web: break out `show password`-enabled input field into its own component
Provides a `show password` field, but as a LightDOM-oriented web component. This form of
input[type="password"] is for flows only, as it has a number of specializations for understanding a
flow's validating round-trip, possible error messages within the challenge, and is left within the
LightDOM both to support compatibility issues and to avoid using `elementInterals`, which is a DOM
feature not supported by some older browsers.
Avoids having to maintain two different instances of the same logic, both for permitting 'show
password', and for handling it.
* web: update PasswordStageForm according to lit-analyzer
With lit-analyzer in the mix and functional, we're seeing new complaints about
inconsistent typing in lit objects, and this was one of them.
* Another lit-analyze error found.
