fix: cap number pad on remaining amount screens#585
Open
CypherPoet wants to merge 4 commits into
Open
Conversation
4 tasks
![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: 5f439703d6
ℹ️ 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".
7 tasks
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/amount-screens-cap
branch
from
b96b812 to
6af6d68
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.
Applies the maxAmountOverride cap (from the send-amount fix) to the LNURL pay/withdraw, spending, advanced-spending, and manual channel-funding screens, so the number pad refuses entry above each screen's contextual maximum. FundManualAmountView also gains the previously-missing upper-bound button validation, which let users proceed above the fundable balance. Receive and CJIT amount screens are intentionally left uncapped (a receive amount has no balance ceiling).
CypherPoet
force-pushed
the
fix/amount-screens-cap
branch
from
6af6d68 to
bd7a772
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on
Depends on #584 (
fix: cap send amount pad at available balance), which introduces themaxAmountOverridemechanism this PR reuses. Merge #584 first. This PR targetsmaster, so until #584 lands its diff also contains #584's commit (1a5b8c62); review thefix: cap number pad input on remaining amount screenscommit (5f439703) for this PR's changes.Description
Building on the send-amount cap (#346), this PR applies the same number-pad cap to the other amount-entry screens that have a contextual maximum: LNURL pay, LNURL withdraw, transfer-to-spending, advanced spending, and manual external channel funding. Each now refuses entry above its limit instead of relying on the Continue button alone.
It also closes a gap on the manual external-funding screen, where Continue stayed enabled for amounts above the fundable balance; that screen is now gated on the available balance like the others.
The receive and CJIT amount screens are intentionally left uncapped: a receive amount has no balance ceiling.
Linked Issues/Tasks
Related: #346
Screenshot / Video
pr2-spending-amount-cap.mp4
QA Notes
Manual Tests
regression:Receive / CJIT Amount: no upper cap; any amount can still be entered.Automated Checks
BitkitTests/NumberPadTests.swift(added in Create swift.yml #4); these screens are view-level wiring plus one button-validation fix, verified by build + manual QA.BitkitTests/NumberPadTestspasses (24 tests).