Description

Fixes a swap display gap during slippage-triggered quote refetches. When the BridgeController temporarily clears activeQuote before the next quote is available, BridgeView could fall through to quote mode even though QuoteDetailsCard and BridgeViewFooter had nothing usable to render. That produced the blank state seen in the ticket: no footer and no loading skeleton.

This keeps needsNewQuote scoped to its original expired-quote retry purpose, and moves the transient empty-quote handling into BridgeView content mode selection. For a non-zero input with no active quote, no retry state, and no terminal quote error/no-quotes state, the view now renders the existing quote skeleton until a refreshed quote is available. That keeps the loading state visible without adding hook-level quote history or reusing quote state across token pair changes.

The swap action smoke test custom slippage path and matching analytics expectation are restored now that the slippage refetch gap has a visible loading state.

Changelog

CHANGELOG entry: Fixed a bug that could leave the swap quote area blank during slippage refresh

Related issues

Fixes: #29615

Manual testing steps

Feature: Swap quote refetch loading state

  Background:
    Given I am logged into MetaMask Mobile
    And I am on the Wallet screen with enough ETH to swap

  Scenario: user updates custom slippage while a swap quote refetches
    Given I start a swap from ETH to USDC on Ethereum
    And a swap quote has loaded

    When user opens slippage settings
    And user enters custom slippage of "3.5"
    And the quote refetch starts
    Then the quote area should show a loading skeleton while the refreshed quote is unavailable
    And the quote area should not become blank
    And when the quote resolves, the quote details and submit action should be visible

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
• 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.