fix: add fallback on chart load errors

[sahar-fehri]

Description

When the TradingView charting library fails to load in the advanced token-details chart (bad CDN URL, network error, widget init failure), users previously saw a plain "Failed to load chart" message inside the WebView shell even though OHLCV data was available.

This PR adds a graceful fallback to the legacy price chart when WebView init fails before CHART_READY, and avoids flashing the advanced time-range selector during that window.

Changes:

• AdvancedChart: New optional onInitFailed callback. Pre-CHART_READY ERROR messages (and native WebView errors) delegate to the parent instead of rendering AdvancedChart's error UI when onInitFailed is provided. Post-CHART_READY errors are unchanged (telemetry only; chart stays visible). Also fixes pre-ready errors arriving before onLoadEnd from leaving the skeleton stuck (removed webViewLoadedRef gate).

• Price.advanced: Wires onInitFailed to fall back to PriceLegacy when OHLCV data is sufficient. Extends chartInitFailed to tri-state (null = init pending, false = ready, true = failed) so shouldFallbackToLegacy and TimeRangeSelector loading stay in sync — selector skeleton until the chart reveals or legacy fallback kicks in.

• Tests: Coverage for init-failure legacy fallback, onInitFailed delegation, pre-ready error UI when no handler, and TimeRangeSelector loading behavior.

Changelog

CHANGELOG entry: Fixed token details advanced chart to fall back to the legacy price chart when the TradingView library fails to load, instead of showing a broken chart error state.

Related issues

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

Manual testing steps

Feature: Advanced chart init failure fallback

  Scenario: CDN / library load failure falls back to legacy chart
    Given advanced token overview chart is enabled
    And MM_CHARTING_LIBRARY_URL is invalid (e.g. typo or unreachable URL)
    When user opens token details for a token with OHLCV data
    Then user does not see "Failed to load chart" plain text
    And user sees the legacy price chart with legacy time-range controls
    And advanced time-range pills (1H, 1D, 1W…) do not flash before legacy appears

  Scenario: Valid CDN shows advanced chart normally
    Given MM_CHARTING_LIBRARY_URL is correct
    When user opens token details for a token with OHLCV data
    Then advanced TradingView chart loads
    And advanced time-range selector appears after the chart skeleton clears

Local CDN failure repro: set MM_CHARTING_LIBRARY_URL to an invalid value in .js.env, rebuild, open token details.

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.

---

Note

Low Risk
Scoped to advanced chart error handling and token-overview fallback UX; post-ready chart behavior is unchanged and tests cover the new paths.

Overview
When the TradingView WebView fails before CHART_READY (CDN, library boot, or native WebView error) but OHLCV data is already available, token details no longer show the advanced chart’s “Failed to load chart” state.

AdvancedChart adds optional onInitFailed. Pre-ready ERROR messages and WebView load failures call the parent instead of rendering the built-in error UI when that handler is set; post-ready errors still only notify via onError. The old webViewLoadedRef gate on pre-ready errors is removed so init failures that arrive before onLoadEnd are handled correctly.

Price.advanced tracks init with tri-state chartInitFailed (null pending, false ready, true failed), includes init failure in shouldFallbackToLegacy, and renders PriceLegacy. TimeRangeSelector stays in a loading/skeleton state until the chart skeleton clears or legacy fallback applies, avoiding a flash of advanced range pills. Visibility traces record chartInitFailed on init failure.

Tests cover delegation, legacy fallback, selector loading, and unchanged error UI when onInitFailed is omitted.

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

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[mm-token-exchange-service]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• Screenshots/Recordings section is empty. Add an image/video for user-facing changes, logs/console output for non-user-facing changes, or write N/A if no evidence is applicable.
• Pre-merge author checklist has unchecked items (e.g. "I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards."). Every box must be consciously checked — see docs/readme/ready-for-review.md.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 90%

click to see 🤖 AI reasoning details

E2E Test Selection:
The PR changes are entirely contained within the AdvancedChart and Price.advanced components:

1. AdvancedChart.types.ts: Adds onInitFailed prop to AdvancedChartProps - a new optional callback for pre-CHART_READY failures.

2. AdvancedChart.tsx: Implements the onInitFailed callback - when a chart init error occurs before the chart is ready and onInitFailed is provided, it delegates to the parent instead of showing error UI. This is a resilience improvement.

3. Price.advanced.tsx: Uses onInitFailed to trigger fallback to the legacy chart when TradingView initialization fails. Adds chartInitFailed state tracking and keeps TimeRangeSelector in loading state until chart is revealed.

4. Test files: Unit tests for the new behavior only.

Why no E2E tags are needed:

• Changes are isolated to chart error handling/fallback logic in the asset overview price chart
• This is a resilience improvement (graceful degradation when TradingView CDN/library fails to load)
• No changes to navigation, confirmations, accounts, networks, swaps, staking, or any other major wallet flows
• No changes to controllers, Engine, or critical infrastructure
• The normal (success) rendering path is unchanged - only the error path is modified
• All new behavior is covered by unit tests
• No existing E2E tests test TradingView chart initialization failure scenarios
• The Price.tsx importers (Perps components) use it for live price display, not the advanced TradingView chart

The risk to existing E2E tests is negligible as the changes only affect error handling in a display component.

Performance Test Selection:
The changes are to chart error handling/fallback logic only. The normal rendering path (success case) is unchanged. The @PerformanceAssetLoading tag covers asset loading performance, but these changes don't affect the performance of asset loading - they only add a fallback mechanism when TradingView initialization fails. No performance-sensitive code paths are modified.

View GitHub Actions results

[sonarqubecloud]

Quality Gate failed

Failed conditions
71.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud