fix(activity): correct EVM rows when non-EVM account selected

[wachunei]

Description

Activity’s unified transaction list passes selectedAddress into TransactionElement and Redux token selectors keyed by account. Those paths previously used the globally selected internal account. After switching the Activity network filter from a non-EVM network (e.g. Bitcoin) back to all popular networks, the selected account could still be non-EVM while EVM transactions remained in the list. EVM sends were compared against a non-EVM address (wrong direction / “Received”), and token metadata was looked up under the wrong account key on each chain (“Not available”).

This change passes the account group’s EVM address for EVM rows (UnifiedTransactionsView), re-decodes when selectedAddress changes (TransactionElement), and adds selectTokensByChainIdAndWalletAddress so token maps match the same wallet address used for decoding.

Changelog

CHANGELOG entry: Fixed Activity showing incorrect Sent/Received labels and "Not available" amounts after switching from a non-EVM network filter back to all popular networks.

Related issues

Fixes: #28035

Refs: https://consensyssoftware.atlassian.net/browse/TMCU-602

Manual testing steps

Feature: Activity unified list after network filter change

  Scenario: EVM sends stay correct after non-EVM filter then popular networks
    Given the user has confirmed token sends on an EVM network (e.g. Linea)
    And Activity Transactions tab is open with the network filter set to that EVM chain

    When the user switches the filter to a non-EVM network (e.g. Bitcoin)
    And the user switches the filter back to all popular networks

    Then top EVM transactions still show Sent (not Received) with token amounts and fiat where applicable (not "Not available")

Screenshots/Recordings

Before

see video on this comment from #28035

After

fix_activity.mp4

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.

---

Note

Medium Risk
Changes how Activity derives the address used to classify EVM transactions and fetch per-chain token metadata, which can alter Sent/Received labeling and displayed amounts across the unified list. Risk is limited to UI/state selection logic and is covered by added selector tests.

Overview
Fixes unified Activity rendering when a non-EVM account remains selected by ensuring EVM list rows use the account group’s EVM address for direction/decoding and token metadata.

UnifiedTransactionsView now passes the account group EVM address into TransactionElement, TransactionElement re-decodes when selectedAddress changes, and token lookup is switched to a new selector selectTokensByChainIdAndWalletAddress (with tests) so token maps are keyed by the same explicit wallet address rather than the globally selected account.

^{Reviewed by Cursor Bugbot for commit 7910a16. Bugbot is set up for automated code reviews on this repo. Configure here.}

[wachunei]

There's a potential on this fixing #29713 as well

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeWalletPlatform, SmokeNetworkExpansion
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 82%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes fix a bug in transaction history display for multi-chain account groups (EVM + Solana). Specifically:

1. New selector selectTokensByChainIdAndWalletAddress: Allows looking up tokens by an explicit wallet address rather than the globally selected account. This is needed when a non-EVM (e.g., Solana) account is selected but EVM transactions need to display correct token information.

2. TransactionElement update: Now accepts an optional selectedAddress prop override and uses the new selector, so token data is fetched for the correct EVM address even when a non-EVM account is globally selected.

3. UnifiedTransactionsView update: Passes selectedAccountGroupEvmAddress (the EVM address from the account group) to TransactionElement, fixing token display in the activity/history view for multi-chain account groups.

Tag selection rationale:

• SmokeWalletPlatform: The UnifiedTransactionsView is directly tested by tests/smoke/wallet/incoming-transactions.spec.ts which is tagged SmokeWalletPlatform. Transaction history display (incoming/outgoing ETH transactions, token transfer details) is a core part of this tag.
• SmokeNetworkExpansion: The fix specifically addresses the case where a Solana account is selected in a multi-chain account group, and EVM transactions need to show correct token info. This is a Solana/non-EVM account interaction scenario that falls under SmokeNetworkExpansion.

Not selected:

• SmokeConfirmations: The TransactionElement is used in transaction history, not directly in confirmation flows.
• SmokeSwap/SmokeStake: No changes to swap or stake flows.
• Other tags: No relevant impact.

Performance Test Selection:
The changes are bug fixes for token selector logic and address resolution in transaction history. They don't introduce new rendering paths, list components, or data loading patterns that would meaningfully impact performance. The new selector uses the same memoization pattern (createDeepEqualSelector) as the existing one. No performance tests are warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
92.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud