Description

This branch wires up the existing onSelectAccount route param on AccountSelectorParams so callers opening the picker via createAccountSelectorNavDetails receive a callback on every tap inside the picker — including taps on the already-selected account.

Previous behaviour: The onSelectAccount route param was declared on AccountSelectorParams but never invoked anywhere. Consumers that needed to know "the user committed a selection" had to read Redux state diffs on AccountTreeController:selectedAccountGroupChange, which does not emit when the user re-taps the already-selected account. Combined with the fact that both tap-commit and back-out paths end in navigation.goBack(), callers had no signal to distinguish a same-account commit from a dismiss.

New behaviour:

1. Tap any account (different or same) — _onSelectMultichainAccount calls setSelectedAccountGroup (existing behavior), then invokes the route param onSelectAccount(accountGroup), then closes. The callback fires regardless of whether the controller actually emitted a state change.
2. Back out / dismiss — Unchanged: navigation.goBack() only; callback does NOT fire.
3. No callback provided — Unchanged: picker behaves identically to before.

Signature updated from (address: string) => void to (accountGroup: AccountGroupObject) => void to match the multichain context. No production caller passes this route param today (verified via repo-wide search for createAccountSelectorNavDetails), so this is a safe, additive surface change.

Why

• Re-tapping the already-selected account inside a generic picker is a real user signal in flows that have a "virtual" funding source layered on top of the regular account (e.g. Money Account as Card funding source on the spending limit screen). Without this callback, consumer screens have no way to detect it.
• Wiring the existing param keeps the public surface unchanged and avoids introducing a parallel naming convention.

What changed (scoped paths)

Out of scope (intentional)

• Other selector components that have their own component-level onSelectAccount prop (MultichainAccountSelectorList, AccountListCell, AccountConnectSingleSelector, etc.) — none touched.
• No changes to controllers, messengers, or default picker behavior for any existing consumer.

Changelog

CHANGELOG entry: Wired the existing onSelectAccount route param on the global Account Selector picker so callers receive a callback on every account tap (including re-tapping the already-selected account), enabling consumer screens to distinguish a committed selection from a dismiss.

Related issues

Fixes:

Used by companion PR #30320 (Card spending limit) to detect the "user is exiting Money Account mode by re-tapping the same regular account" case.

Manual testing steps

Feature: Optional onSelectAccount callback on the global Account Selector picker

  Background:
    Given a caller opens the Account Selector via createAccountSelectorNavDetails
    And the user has more than one account group

  Scenario: caller passes onSelectAccount and the user taps a different account
    When the user taps an account group different from the current one
    Then the picker calls setSelectedAccountGroup with the tapped group's id
    And the onSelectAccount callback is invoked with the tapped account group
    And the picker closes

  Scenario: caller passes onSelectAccount and the user re-taps the already-selected account
    When the user taps the account group that is already selected
    Then setSelectedAccountGroup is still called (no state change emitted)
    And the onSelectAccount callback is invoked with the tapped account group
    And the picker closes

  Scenario: caller passes onSelectAccount and the user dismisses without picking
    When the user taps the back arrow / swipes the picker down
    Then the onSelectAccount callback is NOT invoked
    And the picker closes

  Scenario: caller does NOT pass onSelectAccount (existing flows)
    Given the caller opens the picker without the onSelectAccount route param
    When the user taps any account
    Then the picker behaves identically to before (setSelectedAccountGroup + close)
    And no error is thrown

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.