Description

When switching between time ranges (1H, 1D, 1W, 1M, 1Y) on the token details advanced chart, the headline price visibly jumps through 3-4 intermediate values before settling (~$3+ range on ETH). This creates a jarring flicker experience.
Root cause: Three data sources provide slightly different "current price" values, and during a time-range switch the headline cycles through all of them in sequence:

1. Stale lastBarClose from the previous time range's ohlcvData (still in memory before the new API call returns)
2. New lastBarClose from the fresh /v3/ohlcv-chart response (bucketed candle close — lags behind real price by minutes/hours depending on interval granularity)
3. /v3/ohlcv/latest poll result (fresher candle snapshot)
4. WebSocket tick (true real-time price)
   When the user switches time ranges, the WS unsubscribes and realtimeClose becomes undefined, causing the headline to fall back to stale candle data. The coarser the candle interval, the more pronounced the stale price (daily candles on 1Y can be hours old).

Fix

Hold the last known WS/realtime price in a ref during time-range transitions. The headline stays stable until fresh realtime data arrives from /latest or WS (~500ms after switch).

const lastRealtimeRef = useRef<number | undefined>(undefined);
if (realtimeClose !== undefined) {
  lastRealtimeRef.current = realtimeClose;
}
const stablePrice = realtimeClose ?? lastRealtimeRef.current;

const displayPrice =
  crosshairData?.close ?? stablePrice ?? lastBarClose ?? currentPrice;

Changelog

CHANGELOG entry: stabilize headline price in token details.

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3314

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

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.