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

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.