fix: Prevent coercing symbols to zero in the edit spending cap modal

[pedronfigueiredo]

Description

Since the TextField in the "edit spending cap" modal has a type TextFieldType.Number, it already blocks most symbols and letters. However, it does currently support +, - and e characters as they can be used to construe numbers.

For example, when a - sign is introduced in the input field, the interim value is coerced to '', as there is no numerical equivalent to the sign by itself. The first part of this fix was to disable the "Save" button on such cases. If the user wants to revoke the spending cap, they can introduce 0, but '' is not a valid response.

Furthermore, when a valid number is introduced but that uses scientific notation or +/- signs, the submission is disabled and a validation message is shown to the user: "Enter numbers only".

Related issues

Fixes: #28096

Manual testing steps

1. Deploy an erc20 token contract in the test DApp
2. Trigger an approve confirmation
3. Attempt to edit the spending cap with -1, 10e10, or any others.
4. You should be prevented from submitting and see the validation message.

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension 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]

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.

[metamaskbot]

Builds ready [e0b1cf3]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6
  • common: 0, 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9
  • content-script: 0
  • offscreen: 0
  • ui: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (1931 ± 101 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	1688	2595	1936	214	103
		domContentLoaded	1676	2546	1907	202	97
		load	1687	2605	1931	210	101
		domInteractive	16	97	52	24	12
		backgroundConnect	9	112	29	27	13
		firstReactRender	46	198	105	40	19
		getState	4	69	19	20	10
		initialActions	0	1	0	0	0
		loadScripts	1149	1845	1393	174	83
		setupStore	11	72	27	22	11
		uiStartup	1901	2775	2170	198	95

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 0 Bytes (0.00%)
• ui: 177 Bytes (0.00%)
• common: 63 Bytes (0.00%)

[matthewwalsh0]

Minor, is it worth a constant for the regex such as SPECIAL_CHARACTERS_PATTERN?

[matthewwalsh0]

Minor, is it worth a local Error component to avoid the duplication with the above decimal error?

[sleepytanya]

@pedronfigueiredo
User can use 0 as an input (Spending Cap request turns into Remove Permission) - expected behavior? Thank you!

spendingCapZero.mov

[pedronfigueiredo]

Hey @sleepytanya, thanks for flagging this. It is expected!