Add Done button to change-password success screen

[theDavidCoen]

Summary

• Adds a Done button on the success state of Settings → Change password, using the same bottom-button pattern as Unlock wallet.
• Tapping Done navigates back to Home (Pages.Wallet).
• Other success screens (send, receive, notes, init, mint) are unchanged.

Context

Developed and tested locally with Cursor on branch feat/success-done-button-home.

Test plan

• Change password → success screen shows Done at the bottom
• Done returns to wallet Home
• Other success flows still use their original CTAs (Sounds good, Go to wallet, etc.)

Made with Cursor

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• next-version

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9d8f6217-e4e6-46ce-a730-e03a4fe91496

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ghost]

Review: ✅ Approved

Scope: Pure UI change — adds a "Done" button on the change-password success screen that navigates to Pages.Wallet. No protocol, crypto, key-handling, or security logic is touched.

What I checked

1. src/components/Success.tsx — New SuccessDoneButton export is a clean, minimal wrapper around the existing ButtonsOnBottom + Button components. No issues.

2. src/screens/Settings/Password.tsx — The ternary {successText ? <SuccessDoneButton .../> : <ButtonsOnBottom>...} correctly replaces the previous {successText ? null : ...} pattern. Navigation target Pages.Wallet is the standard root page. Import of NavigationContext + Pages follows the same pattern as Init/Success.tsx and other screens.

3. Cross-repo impact: None. No public API, type, proto, or interface changes. The SuccessDoneButton export is internal to the wallet app. No other repo imports from wallet/src/components/Success.

4. Existing consumers of Success.tsx: Init/Success.tsx and Wallet/Notes/Success.tsx use the default export only — the new named export doesn't affect them.

5. No protocol-critical code touched: Password change flow (saveNewPassword) is unchanged. Key derivation, mnemonic handling, biometrics registration — all untouched. This PR only changes what happens after a successful password change (showing a button instead of nothing).

6. Pattern consistency: Matches Init/Success.tsx which does the same useContext(NavigationContext) + navigate(Pages.X) pattern inside a ButtonsOnBottom.

No issues found.

🤖 Reviewed by Arkana

[ghost]

Review: ✅ Approved

Scope: Pure UI change — adds a "Done" button on the change-password success screen that navigates to Pages.Wallet. No protocol, crypto, key-handling, or security logic is touched.

What I checked

1. src/components/Success.tsx — New SuccessDoneButton export is a clean, minimal wrapper around the existing ButtonsOnBottom + Button components. No issues.

2. src/screens/Settings/Password.tsx — The ternary {successText ? <SuccessDoneButton .../> : <ButtonsOnBottom>...} correctly replaces the previous {successText ? null : ...} pattern. Navigation target Pages.Wallet is the standard root page. Import of NavigationContext + Pages follows the same pattern as Init/Success.tsx and other screens.

3. Cross-repo impact: None. No public API, type, proto, or interface changes. The SuccessDoneButton export is internal to the wallet app. No other repo imports from wallet/src/components/Success.

4. Existing consumers of Success.tsx: Init/Success.tsx and Wallet/Notes/Success.tsx use the default export only — the new named export doesn't affect them.

5. No protocol-critical code touched: Password change flow (saveNewPassword) is unchanged. Key derivation, mnemonic handling, biometrics registration — all untouched. This PR only changes what happens after a successful password change (showing a button instead of nothing).

6. Pattern consistency: Matches Init/Success.tsx which does the same useContext(NavigationContext) + navigate(Pages.X) pattern inside a ButtonsOnBottom.

No issues found.

🤖 Reviewed by Arkana

[bordalix]

In my opinion this could be done in a simpler way:

• don't touch Success component
• Implement button on success to be like this:

      {successText ? (
        <ButtonsOnBottom>
          <Button onClick={() => navigate(Pages.Wallet)} label='Continue' />
        </ButtonsOnBottom>
      ) : (
        <ButtonsOnBottom>
          <Button onClick={handleContinue} label={label} disabled={newPassword === null || saving} loading={saving} />
          {wallet.lockedByBiometrics || !isBiometricsSupported() ? null : (
            <Button onClick={registerUserBiometrics} label='Use biometrics' secondary />
          )}
        </ButtonsOnBottom>
      )}

Full diff:

diff --git a/src/screens/Settings/Password.tsx b/src/screens/Settings/Password.tsx
index 275bf756..f3ceb78e 100644
--- a/src/screens/Settings/Password.tsx
+++ b/src/screens/Settings/Password.tsx
@@ -14,9 +14,11 @@ import ButtonsOnBottom from '../../components/ButtonsOnBottom'
 import { isBiometricsSupported, registerUser } from '../../lib/biometrics'
 import { getPrivateKey, isValidPassword, noUserDefinedPassword, setPrivateKey } from '../../lib/privateKey'
 import { hasMnemonic, getMnemonic, setMnemonic } from '../../lib/mnemonic'
+import { NavigationContext, Pages } from '../../providers/navigation'
 
 export default function Password() {
   const { updateWallet, wallet } = useContext(WalletContext)
+  const { navigate } = useContext(NavigationContext)
 
   const [authenticated, setAuthenticated] = useState(false)
   const [oldPassword, setOldPassword] = useState('')
@@ -98,7 +100,11 @@ export default function Password() {
           </Padded>
         )}
       </Content>
-      {successText ? null : (
+      {successText ? (
+        <ButtonsOnBottom>
+          <Button onClick={() => navigate(Pages.Wallet)} label='Continue' />
+        </ButtonsOnBottom>
+      ) : (
         <ButtonsOnBottom>
           <Button onClick={handleContinue} label={label} disabled={newPassword === null || saving} loading={saving} />
           {wallet.lockedByBiometrics || !isBiometricsSupported() ? null : (

[arkana-ai-bot]

Small, self-contained UI change. Not protocol-critical (no VTXO / signing / forfeit / round / exit surface touched). Behaviour matches the pattern used in src/screens/Wallet/Unlock.tsx:20 (navigate(Pages.Wallet)), and Pages.Wallet is a registered root page (src/providers/navigation.tsx:89), so the navigation target is safe.

Diff review — src/components/Success.tsx:14-20 and src/screens/Settings/Password.tsx:14,21,103-105:

• Correctness: SuccessDoneButton renders <ButtonsOnBottom><Button label='Done' /></ButtonsOnBottom>, which is structurally identical to the fallback branch that was previously hidden on success. The success screen used to have no bottom CTA at all, so this is a pure UX addition — no regression to the other flows, which was the PR's explicit intent.
• No new failure modes: onClick only calls navigate(Pages.Wallet); no async, no promise swallowing, no state mutation. The Header's back control is still present, so users retain both paths.
• Cross-repo: React component internal to wallet; grep confirms SuccessDoneButton is only referenced from Settings/Password.tsx. No public API/proto/type change.
• Danger: passed.

Nits (non-blocking):

1. Naming — SuccessDoneButton lives in Success.tsx but doesn't render <Success>; it's just a footer button. If this helper is expected to stay Password-only, inlining the 3-line JSX in Password.tsx avoids the coupling; if it's meant to be reused across other success screens (Init/Success.tsx, Wallet/Send/Success.tsx, Wallet/Receive/Success.tsx, Wallet/Notes/Success.tsx, Apps/Assets/MintSuccess.tsx), those callsites still have their own bespoke CTAs — worth a follow-up decision.
2. No test added. src/test/App.test.tsx:226 renders the Password settings screen but only asserts navbar visibility. A brief render-and-click test on the success state would lock the new navigation, though not strictly required for a change this size.
3. 'Done' is a hardcoded string — consistent with the rest of the codebase, which has no i18n layer, so fine.

No security, key-handling, or protocol concerns. LGTM once the nits above are considered.