fix(browser): update URL bar after JS cross-origin redirect

[joaoloureirop]

Description

onLoadEnd only updated the URL bar when started && ended or the origin was unchanged. A JavaScript window.location.href navigation to another origin often has no matching onLoadStart, so the bar kept the previous origin.

A completed load on a new origin is now treated as a committed navigation. The skipped Appium coverage for this path is enabled again.

Changelog

CHANGELOG entry: Fixed the in-app browser URL bar not updating after a JavaScript cross-origin redirect

Related issues

Fixes: #33815

Manual testing steps

Feature: in-app browser URL bar

  Scenario: URL bar updates after JS cross-origin redirect
    Given the user is on the in-app browser
    When a page sets window.location.href to another origin
    Then the URL bar shows the new origin

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.

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeBrowser
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 95%

click to see 🤖 AI reasoning details

E2E Test Selection:
The PR makes targeted changes to the in-app browser:

1. App fix (BrowserTab.tsx): Adds isCommittedCrossOriginRedirect condition to handleSuccessfulPageResolution so the URL bar correctly updates after JS-initiated cross-origin redirects (window.location.href). This fixes issue [Browser] URL bar does not update after JS-initiated cross-origin redirect #33815 where the URL bar kept showing the previous origin after a cross-origin redirect.

2. Unit test (index.test.tsx): Adds a unit test covering the new cross-origin redirect behavior.

3. Page object (BrowserView.ts): Adds expectUrlToContain() helper that works across both Appium and non-Appium frameworks, with retry logic for Appium.

4. Smoke spec (browser-navigation.spec.ts): Un-skips the 'displays redirected URL after cross-origin redirect' test (previously skipped due to the bug now fixed) and updates it to use the new expectUrlToContain() helper.

All changes are scoped to the Browser feature area. The smoke spec lives in tests/smoke-appium/wallet/browser/ which maps directly to SmokeBrowser. No other user flows (accounts, confirmations, networks, swaps, etc.) are affected. The SmokeBrowser tag is the correct and only tag needed.

Performance Test Selection:
No performance-sensitive code paths are changed. The fix is a conditional logic change in URL bar update logic (handleSuccessfulPageResolution) that only affects cross-origin redirect scenarios. No rendering loops, asset loading, or startup flows are impacted. No performance spec files were changed.

View GitHub Actions results

[github-actions]

🧪 Flaky unit test detection

Run history flaky detection

View recent run history

Historical failure rate is a hint, not proof — review each suggestion in context. See the flaky-test-detection skill for the full pattern reference and manual audit workflow.

Failures / runs sampled per window:

File	7d	15d	30d
app/components/Views/BrowserTab/index.test.tsx	0/136	0/179	0/374

AI-detected flaky patterns

app/components/Views/BrowserTab/index.test.tsx

• J4 — waitFor without a real assertion inside (high)
  • The waitFor function is used without a real assertion inside it, which can lead to the test resolving immediately without verifying the expected condition. This can cause intermittent failures as the test may pass without actually validating the intended behavior.
  • Suggested fix in app/components/Views/BrowserTab/index.test.tsx:

    -await waitFor(() =>
    -
    +await waitFor(() => {
    +  expect(screen.getByTestId('browser-webview')).toBeOnTheScreen();
    +});

This check is informational only and does not block merging.