feat: Implement edit spending cap modal for approve confirmations

[OGPoyraz]

Description

This PR aims to implement edit spending cap modal for ERC20 tokens in approve confirmations.

As this is the last functional PR for approve confirmations - it also adds feature flag instead of env variable hard disables it.

This spending cap modal also includes validations which is demonstrated in the screenshots section.

Related issues

Fixes: #16833

Manual testing steps

1. Go to test dapp
2. Deploy ERC20 token
3. Use "approve tokens" or "increase token allowance" button

Screenshots/Recordings

Before

After

spending.cap.modal.mp4

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.

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 5d1bab3
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/c0fe4bfa-1e38-4235-883e-f111e8814626

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

Tip

• Check the documentation if you have any doubts on how to understand the failure on bitrise

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 90.51724% with 11 lines in your changes missing coverage. Please review.

Project coverage is 72.46%. Comparing base (33b8046) to head (5d1bab3).
Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
...s/Views/confirmations/utils/validations/approve.ts	87.87%	2 Missing and 2 partials ⚠️
...ations/approve-and-permit2/approve-and-permit2.tsx	50.00%	0 Missing and 3 partials ⚠️
...decrease-allowance/increase-decrease-allowance.tsx	40.00%	0 Missing and 3 partials ⚠️
...onfirmations/hooks/useApproveTransactionActions.ts	90.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16856      +/-   ##
==========================================
+ Coverage   72.40%   72.46%   +0.06%     
==========================================
  Files        2709     2726      +17     
  Lines       58754    59084     +330     
  Branches     9254     9342      +88     
==========================================
+ Hits        42540    42818     +278     
- Misses      13517    13527      +10     
- Partials     2697     2739      +42     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 03662bd
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/ed8b73ad-9e2e-49fa-bd8c-b93514d6a1c5

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

Tip

• Check the documentation if you have any doubts on how to understand the failure on bitrise

[cursor]

Bug: Spending Cap Validation Fails for Comma Separators

The spending cap validation logic in app/components/Views/confirmations/utils/validations/approve.ts contains multiple issues:

• The validateValueIsPositive function fails to normalize comma decimal separators (e.g., "123,45") before parsing, leading to incorrect positive value checks. It also incorrectly allows negative values.
• The validateAmountIsValidNumber function's regex /^\d*\.?\d+$/ incorrectly rejects valid integer inputs (e.g., "123").

app/components/Views/confirmations/utils/validations/approve.ts#L3-L32

metamask-mobile/app/components/Views/confirmations/utils/validations/approve.ts

Lines 3 to 32 in 03662bd

	const validateValueIsPositive = (
	newSpendingCap: string,
	approveMethod: ApproveMethod,
	) => {
	if (parseFloat(newSpendingCap) > 0) {
	return false;
	}
	if (parseFloat(newSpendingCap) === 0) {
	if (
	approveMethod === ApproveMethod.INCREASE_ALLOWANCE ||
	approveMethod === ApproveMethod.DECREASE_ALLOWANCE
	) {
	return strings(
	approveMethod === ApproveMethod.INCREASE_ALLOWANCE
	? 'confirm.edit_spending_cap_modal.no_zero_error_increase_allowance'
	: 'confirm.edit_spending_cap_modal.no_zero_error_decrease_allowance',
	);
	}
	return strings('confirm.edit_spending_cap_modal.no_zero_error');
	}
	return false;
	};
	const validateAmountIsValidNumber = (newSpendingCap: string) => {
	const normalizedValue = newSpendingCap.replace(',', '.');
	if (!/^\d*\.?\d+$/.test(normalizedValue)) {

Fix in Cursor

---

Bug: Modal Stuck Loading Due to Error Handling

The Save button's onPress handler has improper error handling. If onSpendingCapUpdate throws an error, setIsDataUpdating(false) is not called, leaving the modal permanently in a loading state. The async operation should be wrapped in a try-finally block to ensure setIsDataUpdating(false) is always executed.

app/components/Views/confirmations/components/modals/edit-spending-cap-modal/edit-spending-cap-modal.tsx#L102-L108

metamask-mobile/app/components/Views/confirmations/components/modals/edit-spending-cap-modal/edit-spending-cap-modal.tsx

Lines 102 to 108 in 03662bd

	isDisabled={!!error}
	onPress={async () => {
	setIsDataUpdating(true);
	await onSpendingCapUpdate?.(newSpendingCap);
	onClose();
	setIsDataUpdating(false);
	}}

Fix in Cursor

---

Bug: Decimal Mismatch Causes Validation Issues

The ApproveAndPermit2 component uses decimals ?? 1 as the default for the EditSpendingCapButton's decimals prop, while the useApproveTransactionActions hook uses ERC20_DEFAULT_DECIMALS (typically 18) for transaction updates. This inconsistency in default decimal values can cause validation to misalign with actual transaction processing, leading to incorrect input handling.

app/components/Views/confirmations/components/approve-static-simulations/approve-and-permit2/approve-and-permit2.tsx#L82-L83

metamask-mobile/app/components/Views/confirmations/components/approve-static-simulations/approve-and-permit2/approve-and-permit2.tsx

Lines 82 to 83 in 03662bd

	decimals: decimals ?? 1,
	spendingCap: amount ?? '',

Fix in Cursor

---

Was this report helpful? Give feedback by reacting with 👍 or 👎

[sonarqubecloud]

Quality Gate passed

Issues
16 New issues
0 Accepted issues

Measures
2 Security Hotspots
94.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jpuri]

Code changes look good to me.

Code looks very specific to use case of editing spending cap and to make it re-usable we would need to extract more generic code out of it.

[OGPoyraz]

As I've already ran e2e tests 5 times and having the same failures on run_wallet_platform_swimlane_android_smoke https://app.bitrise.io/build/80823645-35b0-4705-9d81-b170edeaa5e7 I am adding No e2e smoke needed label because this failures are not related.