Skip to content

feat(portal): show/hide password toggle on login and setup (bd-2668) - #203

Merged
hatafatif merged 1 commit into
developfrom
bd-2668-03906
Aug 13, 2026
Merged

feat(portal): show/hide password toggle on login and setup (bd-2668)#203
hatafatif merged 1 commit into
developfrom
bd-2668-03906

Conversation

@hatafatif

Copy link
Copy Markdown
Collaborator

Adds the eye toggle to the two password screens that were still typed blind: PortalLogin and PortalSetup.

PortalPasswordResetVerify already had this, so the pattern is copied from there rather than invented — input type flips passwordtext, button absolutely positioned in a relative wrapper, pr-10 so long passwords don't run under the icon.

Decisions worth a look

  • Setup gets ONE toggle for both fields, matching the reset screen. The failure it fixes is "these two don't match and I can't see why" — that needs both visible at once, which a per-field toggle makes harder.
  • Also added aria-label to the pre-existing reset-screen toggle. It was icon-only with no accessible name, so a screen reader announced just "button". Same three lines; shipping two inconsistent copies was the worse option.

Tests

7 new, red-first against develop (6 failed / 1 passed before the fix). They assert on the input's type attribute — what actually masks the characters — because asserting on which icon renders would pass even with the wiring broken. Also pinned: the toggle is type=button, so peeking doesn't submit the form.

  • Portal vitest: 18 files / 97 tests green
  • tsc --noEmit: clean · vite build: clean
  • Root Jest: at its pre-existing 33-suite baseline (root suite runs before bot/ npm ci). Diffed failures by name against clean develop — the one differing suite (exam-confirm-routing) passes in isolation, references zero portal files, and the run-to-run failure count varies on identical code, so it's parallel-load flake, not this change.

Not covered: how it looks on a real phone — worth a human eye.

Closes: bd-2668

🤖 Generated with Claude Code

The login and setup screens were the two places a teacher typed a password
completely blind. Setup is the worse of the two: an 8-character-plus-a-digit
password, typed twice, with "Passwords do not match" as the only feedback —
and it cannot tell you which of the two you fat-fingered. On a phone keyboard
that is a dead end.

PortalPasswordResetVerify already had this toggle, so the pattern is copied
from there rather than invented: the input type flips between 'password' and
'text', the button sits absolutely inside a relative wrapper, and the field
gets pr-10 so a long password does not run under the icon.

Setup gets ONE toggle driving both fields, matching the reset screen. The
failure being fixed is "these two do not match and I cannot see why", which
needs both visible at once; a per-field toggle makes that comparison harder,
not easier.

Also gives the pre-existing reset-screen toggle an aria-label — it was an
icon-only button with no accessible name, so a screen reader announced it as
just "button". Same three-line pattern, and shipping two inconsistent copies
of it was the worse option.

Tests assert on the input's type attribute, which is what actually determines
whether characters are masked; asserting on which icon renders would pass even
if the wiring were broken. Also pinned: the toggle is type=button, so peeking
at your password does not submit the form.

Tests: 7 new (red-first against develop: 6 failed, 1 passed), portal suite
18 files / 97 tests green, tsc clean, vite build clean. Root Jest is at its
pre-existing 33-suite baseline (needs bot/ deps, installed separately in CI).

Closes: bd-2668
@hatafatif
hatafatif merged commit 22d937e into develop Aug 13, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant