chore(runway): cherry-pick fix(perps): correct amount reset when balance changes and simplify setAmount cp-7.65.0

[runway-github]

• fix(perps): correct amount reset when balance changes and simplify setAmount cp-7.65.0 (fix(perps): correct amount reset when balance changes and simplify setAmount cp-7.65.0 #25759)

Description

1. What is the reason for the change?
   When the user changed the payment token or when the effective balance
   dropped, the Perps order form was resetting the amount to max whenever
   the current amount was greater than the new max. That logic could also
   run when the user had intentionally set the amount to 0 or left it empty
   (e.g. initial value 10), and setAmount was forcing empty values to
   '0', which made it harder to preserve the intended initial amount.

2. What is the improvement/solution?

• In the useEffect that reacts to balanceForMax /
  maxPossibleAmount / orderForm.amount: only reset the amount when it
  actually exceeds the new max. If currentAmount === 0,
  maxPossibleAmount === 0, or currentAmount < maxPossibleAmount, we
  return early and do not overwrite the form amount.
• In setAmount, pass through the amount string as-is and remove the
  || '0' fallback so the form can keep an empty or user-chosen initial
  value (e.g. 10) without being forced to '0'.

Changelog

CHANGELOG entry: Fixed Perps order form so the amount is only reset when
it exceeds the new max after changing payment token or balance, and no
longer overwrites an initial or empty amount.

Related issues

Fixes:

Manual testing steps

Feature: Perps order form amount when balance or payment token changes

  Scenario: user has set amount to 10 and then changes payment token
    Given user is on the Perps order view with amount set to 10 (or another value below the new max)

    When user changes the payment token (or balance updates so max possible amount changes)
    Then the amount remains 10 and is not reset to max or to 0

Screenshots/Recordings

Before

No visible change

After

No visible change

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.

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
Small, localized UI state change to Perps order form amount clamping with minimal surface area; main risk is behavior differences around edge cases like 0/empty amounts.

Overview
Fixes Perps order form amount clamping when balanceForMax/maxPossibleAmount changes so it only overwrites the entered amount when the current value is greater than or equal to the new max, and avoids clamping when either value is 0.

This refactors the useEffect to early-return for non-exceeding/zero cases and consistently floor the recalculated max before updating orderForm.amount.

^{Written by Cursor Bugbot for commit 68bf99e. This will update automatically on new commits. Configure here.}

---

Co-authored-by: Cursor cursoragent@cursor.com 985f421

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

[github-actions]

🔍 Smart E2E Test Selection

⏭️ Smart E2E selection skipped - base branch is not main (base: release/7.65.0)

All E2E tests pre-selected.

View GitHub Actions results

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

NaN from empty amount bypasses early return guard

Medium Severity

The old code used Number.parseFloat(orderForm.amount || '0') to safely default empty strings to '0'. The new code uses Number.parseFloat(orderForm.amount) without this fallback, producing NaN when orderForm.amount is empty. Since all comparisons with NaN return false (NaN === 0 is false, NaN < maxPossibleAmount is false), none of the early-return conditions will trigger, causing the amount to be unexpectedly reset to maxPossibleAmount. Every other call site in the codebase (e.g., in PerpsOrderView.tsx) consistently uses orderForm.amount || '0' as a guard before parsing.

 

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[metamaskbot]

No release label on PR. Adding release label release-7.65.0 on PR, as PR was cherry-picked in branch 7.65.0.