Add a password visibility toggle and a Caps Lock indicator to the sign-in and sign-up pages

[BobDu]

The username/password login page and the self-registration page currently provide no way to see the typed password and no warning when Caps Lock is on:

• The login page's password field is a bare <input type="password">. Chrome and Firefox users get neither a reveal control nor a Caps Lock indicator from the browser (Edge ships a native reveal button and WebKit draws a native Caps Lock icon; the other browsers have neither).
• The registration page has had a "Show" checkbox since [JENKINS-50447] New design and slim down of login page #3380, but the login page never received the same treatment, and neither page warns about Caps Lock.

This change adds to both pages:

• an eye button inside the password field that toggles the visibility of the typed password. It is a real <button> with a fixed accessible name and aria-pressed, following the ARIA toggle button pattern, and is only shown when JavaScript is available.
• an in-field Caps Lock indicator (the U+21EA key symbol, drawn in the style of the existing symbols) with a visually hidden status text for screen readers, shown while the focused password field has Caps Lock on. The state is tracked from keydown/keyup/mousedown events page-wide, so the indicator also appears when the field is entered with Caps Lock already on.

The sign-up page's "Show" checkbox is replaced by the same toggle, and both pages share one implementation (src/main/js/util/password-field.js). The built-in password reveal control in Edge (::-ms-reveal) and the native WebKit Caps Lock indicator (::-webkit-caps-lock-indicator) are suppressed on these fields in favor of the cross-browser controls, and the now-unused "Show" translations are removed. Form field names and submission endpoints are unchanged, and no Java code is touched.

Testing done

• Added JenkinsRule smoke tests asserting that both pages render the new controls and that the old checkbox is gone (HudsonPrivateSecurityRealmTest#signupPageHasPasswordVisibilityToggleAndCapsLockIndicator, #loginPageHasPasswordVisibilityToggleAndCapsLockIndicator); the existing signup() and anonymousCantSignup() tests still pass.
• Manually tested against a local build in Chromium:
  • toggling reveals and conceals the password, flips aria-pressed, and does not affect form submission; logging in and registering complete end to end;
  • the Caps Lock indicator appears while typing with Caps Lock on, appears immediately when clicking or tabbing into the field with Caps Lock already on, and disappears when Caps Lock is released or the field loses focus;
  • the password strength indicator and the hidden password2 synchronization on the sign-up page keep working;
  • with JavaScript disabled the toggle stays hidden and the pages degrade to plain password fields.
• yarn lint passes.

Screenshots (UI changes only)

Before

Login	Sign up

After

Login	Sign up

Login, password revealed	Login, Caps Lock on

Proposed changelog entries

• Add a password visibility toggle and a Caps Lock indicator to the login and sign-up pages.

Proposed changelog category

/label rfe,web-ui

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[daniel-beck]

Tentatively doesn't seem worth maintaining this when it's a client problem.

[BobDu]

Browser support here is thin though. Edge has a reveal button, Safari draws a caps lock icon, Chrome only does the caps lock icon on macOS, Firefox has neither. The Chromium request for a non-Mac caps lock indicator has been open since 2009 (https://issues.chromium.org/issues/41271565) — a CL finally showed up in review this month, 17 years in, and it wouldn't cover the reveal side anyway. The Firefox one is from 2004 and still NEW (https://bugzilla.mozilla.org/show_bug.cgi?id=259059). WICG discussed standardizing a caps lock warning and the answer was no: "a browser user interface choice (or limitation) and nothing to be standardized" (https://discourse.wicg.io/t/warn-user-if-caps-lock-is-on-when-entering-password/1946).

The reason I wrote this: we run Jenkins internally, and the team maintaining it keeps getting "can't log in" tickets that turn out to be caps lock or a typo the user couldn't see. That noise lands on whoever operates the instance, and I doubt we're special — any instance on a username/password realm (LDAP/AD use the same page) should see the same.

Core also made this call once already: the sign-up page got a "Show" checkbox in #3380 (2018). This brings the login page up to the same level and replaces the checkbox with the usual eye button. It also fixes the sign-up page currently showing Edge's native reveal control next to its own checkbox.

It's ~40 lines of shared JS, no dependencies, no Java, with smoke tests. If you see the two controls differently I'm fine dropping the caps lock part or splitting the PR.

[janfaracik]

Tentatively doesn't seem worth maintaining this when it's a client problem.

I'm in agreement.

[BobDu]

How about I drop the caps lock indicator and keep only the reveal toggle? For caps lock there's at least a CL in flight on the Chromium side, so I can see waiting for the browser there.

The reveal button is a different story, because the standards discussion settled it the other way around. CSSWG adopted ::reveal-icon into css-forms-1 last year (w3c/csswg-drafts#11845), but the resolution only guarantees the button under the author opt-in appearance: base, and implementation hasn't started anywhere: css-forms-1 is a First Public Working Draft (https://www.w3.org/TR/css-forms-1/), Chrome lists the umbrella feature as Proposed, the Firefox and WebKit tracking bugs are still NEW. The Chrome folks also explained in that thread why they won't ship it by default: they tried in 2020, got compat bugs from pages drawing their own toggle, and re-disabled it. Firefox has had the button implemented since Firefox 96, disabled to this day, not even on Nightly (https://bugzilla.mozilla.org/show_bug.cgi?id=1743046). So even in the standards endgame, whether a login page shows a reveal control is the page's decision and the browser only supplies the hook. This PR now, or appearance: base some years from now, it's our call either way.

Core already made that call for the sign-up page: "Show" has been there since #3380 and survived the #7872 revamp. The trimmed PR is mostly the login page catching up, with the checkbox replaced by the usual eye button and one shared implementation for both pages.

If that works I'll update the PR to drop the caps lock part.