fix: align account selector transitions with main stack

[DostoevskysPiano]

Description

The full-page account list (AccountSelector) animates in Reanimated while the parent stack has animationEnabled: false, so its motion was decoupled from other primary flows. Opening used a much lighter spring than iOS UINavigationController, and closing used a fixed 150ms timing that did not match stack-driven screens (e.g. Settings, token details).

This change applies the same transition spec as @react-navigation/stack horizontal presets: on iOS, withSpring using the library’s TransitionIOSSpec parameters; on Android, withTiming with 400ms and the ScaleFromCenterAndroid bezier easing. Enter and exit both use the same family of motion per platform so the account list should feel consistent with other slide-from-right stack screens.

Validation: ESLint reports no issues on AccountSelector.tsx. Run yarn jest --runTestsByPath app/components/Views/AccountSelector/AccountSelector.test.tsx --watchman=false locally if duplicate .claude/worktrees/ paths affect Jest discovery.

Changelog

CHANGELOG entry: Aligned full-page account list open and close animations with main stack horizontal transition timing

Related issues

No issue: polish / consistency with existing navigation transition presets.

Manual testing steps

Feature: Account list transition consistency

  Scenario: Open and close account list on iOS
    Given the user is on the wallet home with the app running on iOS
    When the user opens the account list and then dismisses it with the back control
    Then the slide in and slide out should feel consistent with opening Settings or a token asset from the wallet

  Scenario: Open and close account list on Android
    Given the user is on the wallet home with the app running on Android
    When the user opens the account list and then dismisses it with the back control
    Then the slide in and slide out duration and easing should feel consistent with other horizontal stack transitions

Screenshots/Recordings

Before

N/A

After

N/A

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 (existing AccountSelector unit tests; no new cases required for timing constants)
• I've documented my code using JSDoc format if applicable (inline comment block only; no new public APIs)
• 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

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.

[github-actions]

CLA Signature Action:

Thank you for your submission, we really appreciate it. We ask that you read and sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just by adding a comment to this pull request with this exact sentence:

I have read the CLA Document and I hereby sign the CLA

By commenting with the above message you are agreeing to the terms of the CLA. Your account will be recorded as agreeing to our CLA so you don't need to sign it again for future contributions to this repository.

0 out of 1 committers have signed the CLA.
❌ @DostoevskysPiano

[DostoevskysPiano]

Validation (local): yarn jest --runTestsByPath app/components/Views/AccountSelector/AccountSelector.test.tsx --watchman=false --forceExit --maxWorkers=2 — 17 tests passed.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeAccounts
• Selected Performance tags: @PerformanceAccountList
• Risk Level: low
• AI Confidence: 85%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes in AccountSelector.tsx are purely animation/visual changes:

1. The open animation is now platform-specific: iOS uses a spring animation with new parameters (damping: 500, mass: 3, stiffness: 1000), Android uses withTiming with a 400ms bezier easing curve.
2. The close animation similarly uses platform-specific animations.
3. No functional logic, state management, navigation, or account selection behavior has changed.
4. The AnimationDuration.Fast constant was replaced with a hardcoded 400ms value.

Since the AccountSelector is a core component used in account switching flows, SmokeAccounts is the most relevant tag to verify the animation changes don't break account selection functionality. The functional behavior (account switching, selection, navigation) remains unchanged, so the risk is low.

CHANGELOG.md is documentation only and requires no testing.

No other tags are needed since:

• No controller changes (no SmokeIdentity, SmokeWalletPlatform needed)
• No network changes (no SmokeNetworkAbstractions needed)
• No transaction/confirmation changes (no SmokeConfirmations needed)
• No browser/snap changes

Performance Test Selection:
The changes directly modify the animation timing and easing for the AccountSelector open/close transitions. The @PerformanceAccountList performance test measures account list rendering and dismissal performance, which is directly impacted by these animation parameter changes. The iOS spring animation parameters changed significantly (damping: 20→500, mass: 0.3→3, stiffness: 500→1000) and Android now uses a 400ms bezier timing instead of the previous spring animation. These changes could affect the measured performance metrics for account list open/close operations.

View GitHub Actions results

[sonarqubecloud]

Quality Gate failed

Failed conditions
66.7% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud