fix: cap send amount pad at available balance#584
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a5b8c62b0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let newAmount = convertToSats(newText, currency: currency) | ||
|
|
||
| if newAmount <= maxAmount { | ||
| if newAmount <= effectiveMaxAmount { |
There was a problem hiding this comment.
When the async cap drops below the current input, or an over-balance invoice/existing amount is prefilled via updateFromSats, this cap check also rejects delete if removing one character still leaves the amount above effectiveMaxAmount. For example, 123456 sats with a 1000 sat cap, or fiat input with trailing decimals like 10.00, cannot be backspaced because rawInputText is never updated after the rejected delete, leaving the user stuck until they tap Available. Deletion/clearing should bypass the cap so users can reduce an invalid amount to a valid one.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This was a good catch: Deletions were going through the same cap check as new
digits, so once an amount was above the cap (a prefilled invoice over the balance,
or a cap that dropped after input) every backspace got rejected and left the user
stuck.
Fixed in 4868096: deletions now always apply, and the cap only blocks
growing the amount. Added a regression test in NumberPadTests covering the
over-cap prefill case (delete reduces it, adding a digit stays blocked).
The send number pad now rejects keystrokes that would push the amount above the available sendable balance, reusing the existing over-max block (haptic + error flash) via a dynamic maxAmountOverride. Continue-button validation is unchanged as a backstop. Closes synonymdev#346
CypherPoet
force-pushed
the
fix/send-amount-cap
branch
from
1a5b8c6 to
d4d8599
Compare
The cap rejected every keystroke whose result still exceeded it, including deletions. When an amount lands above the cap (a prefilled invoice over the available balance, or a cap that dropped after input), the user could not backspace to reduce it, since each intermediate value was still over the cap. Deletions now always apply; the cap only blocks growing the amount.
1 participant
Fixes #346
Description
This PR makes the send amount number pad refuse entry above your available balance. Before, you could type any amount and the screen only disabled the Continue button once you went over; now the number pad itself stops you at the maximum you can send, using the same haptic and error flash it already shows at its upper input limit.
The cap follows the selected wallet: spendable on-chain balance minus the network fee for savings, or outbound capacity minus the routing-fee estimate for spending. Tapping the Available label still fills the exact maximum, and the Continue-button validation stays in place as a backstop.
Linked Issues/Tasks
Fixes #346
Screenshot / Video
prevent-exceeding-max.mp4
QA Notes
Manual Tests
regression:enter a normal under-balance amount: Continue enabled, proceeds to Confirm.regression:zero available balance -> Amount: pad still accepts input (not frozen), Continue stays disabled.Automated Checks
BitkitTests/NumberPadTests.swift(testMaxAmountOverrideBlocksInputAboveBalance,testClearingMaxAmountOverrideRestoresGlobalCap).BitkitTests/NumberPadTestspasses (24 tests).