Skip to content

fix: drop the reveal toggle from a disabled PasswordInput (Issue epam/ai-dial-chat#8791) - #876

Merged
PolinaGurinovich97 merged 1 commit into
fix/optional-editor-peers-build-0.14from
fix/password-input-disabled-toggle-0.14
Sep 14, 2026
Merged

PolinaGurinovich97 merged 1 commit into
fix/optional-editor-peers-build-0.14from
fix/password-input-disabled-toggle-0.14

Conversation

@PolinaGurinovich97

Copy link
Copy Markdown
Collaborator

Cherry-pick of #874 for the 0.14 release line. Applied without conflicts.

Why it belongs on the release branch

0.14.0 is the release that ships the 2.0 PasswordInput, and ai-dial-chat consumes it from the 0.14.0-dev.* line. The field masks correctly while disabled but still draws its reveal button in a disabled state, where the design draws a masked field with nothing after it — ai-dial-chat#8791 is exactly that state: a toolset's OAuth client secret, disabled once the user has logged in.

The second half of the fix matters on its own: masking now resets while disabled, so a form that locks its inputs during a request hands the field back masked instead of silently restoring an earlier reveal with no pressed toggle on screen to explain why a secret had become readable.

No API change; an enabled field behaves exactly as before.

Note on the base branch

This is stacked on #873 (base: fix/optional-editor-peers-build-0.14) rather than on release-0.14 directly, for two reasons:

  1. Verify package distribution is broken on release-0.14 for every PR — the fixtures pin epam-ai-dial-ui-kit-0.0.0.tgz while a release branch packs …-0.14.0.tgz (see fix(fixtures): pack under a canonical name so the suite works on any branch #875). fix: don't break the build of consumers without the editor peers (Issue epam/ai-dial-chat#8719) #873 carries that fix, so stacking makes this PR's gate actually run.
  2. The diff stays limited to the component change instead of duplicating fix: don't break the build of consumers without the editor peers (Issue epam/ai-dial-chat#8719) #873's commits.

GitHub retargets this PR to release-0.14 automatically when #873 merges. If you would rather review it straight against release-0.14, merge #873 first and I will re-point it.

Verification on this branch

  • npm run typecheck — green.
  • PasswordInput spec — 8/8, including the rewritten disabled case (no toggle) and the new reveal → disable → enable case.
  • The full kit suite (183 files, 2494 tests) is green on the development PR with the identical commit.

🤖 Generated with Claude Code

…/ai-dial-chat#8791)

A disabled `PasswordInput` (2.0) masked its value correctly but still drew the
reveal button next to it, disabled. The design draws a masked field with
nothing after it — ai-dial-chat#8791 is exactly that state: a toolset's OAuth
client secret, disabled once the user has logged in — and a control whose only
two outcomes are both unreachable is space spent on nothing.

The toggle is now absent while `disabled`, and masking resets with it: a field
that is disabled and then enabled again comes back masked rather than silently
restoring an earlier reveal. That second half matters on its own — a form that
locks its inputs during a request used to hand the field back revealed, with
no pressed toggle on screen to explain why the secret was readable.

Nothing changes for an enabled field. The spec and the Storybook description
that documented the disabled-but-present toggle now cover its absence and the
re-enable path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@PolinaGurinovich97
PolinaGurinovich97 merged commit dc804f5 into fix/optional-editor-peers-build-0.14 Sep 14, 2026
2 checks passed
@PolinaGurinovich97
PolinaGurinovich97 deleted the fix/password-input-disabled-toggle-0.14 branch September 14, 2026 19:46
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