Description

Activity’s unified transaction list used the globally selected account for the Accounts API infinite query (selectEvmAddress). When a non-EVM account stayed selected (e.g. Bitcoin) but the network filter returned to all popular networks, the query had no EVM address and stayed disabled, so the UI showed only non-EVM rows.

This PR resolves the query to the selected account group’s EVM internal account when present, falling back to the global EVM address otherwise. It also filters confirmed and pending EVM rows to the currently enabled EVM chain IDs so the list matches the Activity network filter (including single-chain vs multi-chain). ConfirmedEvm rows use the same group EVM selectedAddress as pending EVM rows for consistent decode/display with multichain selection.

This builds on the earlier Activity fixes in #29794 (TransactionElement / token map); this branch carries the remaining UnifiedTransactionsView and useTransactionsQuery alignment.

Changelog

CHANGELOG entry: Fixed Activity transaction list not showing EVM history after switching back from a non-EVM network filter to all popular networks, and tightened EVM rows to the enabled network filter.

Related issues

Fixes #29952
Refs: #28035

Manual testing steps

Feature: Activity unified transactions and network filter

  Scenario: EVM history returns when non-EVM account is selected and filter is all popular networks
    Given the user has an account group with both EVM and non-EVM accounts
    And the globally selected account is non-EVM (e.g. Bitcoin)

    When the user opens Activity then sets the network filter to all popular networks

    Then EVM and non-EVM transactions appear in the unified list as expected

  Scenario: Single EVM chain filter only shows that chain
    Given Activity Transactions is open with multiple EVM networks available

    When the user sets the filter to one EVM chain (e.g. Linea) then to another (e.g. Ethereum)

    Then the list updates to transactions for the selected chain only

  Scenario: Pending EVM rows respect enabled chains
    Given the user has a submitted EVM transaction on one chain

    When the user filters Activity to a different single EVM chain

    Then pending rows for other chains do not appear at the top of the list

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.