fix: drop the reveal toggle from a disabled PasswordInput (Issue epam/ai-dial-chat#8791) - #876
Merged
PolinaGurinovich97 merged 1 commit intoSep 14, 2026
Conversation
…/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
requested review from
Alexander-Kezik,
hhharmEpm,
valerydluski and
ya092
as code owners
September 14, 2026 19:44
PolinaGurinovich97
merged commit Sep 14, 2026
dc804f5
into
fix/optional-editor-peers-build-0.14
2 checks passed
PolinaGurinovich97
deleted the
fix/password-input-disabled-toggle-0.14
branch
September 14, 2026 19:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #874 for the 0.14 release line. Applied without conflicts.
Why it belongs on the release branch
0.14.0is the release that ships the 2.0PasswordInput, andai-dial-chatconsumes it from the0.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 onrelease-0.14directly, for two reasons:Verify package distributionis broken onrelease-0.14for every PR — the fixtures pinepam-ai-dial-ui-kit-0.0.0.tgzwhile 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.GitHub retargets this PR to
release-0.14automatically when #873 merges. If you would rather review it straight againstrelease-0.14, merge #873 first and I will re-point it.Verification on this branch
npm run typecheck— green.PasswordInputspec — 8/8, including the rewritten disabled case (no toggle) and the new reveal → disable → enable case.developmentPR with the identical commit.🤖 Generated with Claude Code