Skip to content

fix: cap number pad on remaining amount screens - #2

Closed
CypherPoet wants to merge 1 commit into
fix/send-amount-capfrom
fix/amount-screens-cap
Closed

fix: cap number pad on remaining amount screens#2
CypherPoet wants to merge 1 commit into
fix/send-amount-capfrom
fix/amount-screens-cap

Conversation

@CypherPoet

@CypherPoet CypherPoet commented Jun 5, 2026

Copy link
Copy Markdown
Owner

Depends on

This PR is based on #4's branch (fix/send-amount-cap, fix: cap send amount pad at available balance), which introduces the maxAmountOverride mechanism it reuses. It targets that branch as its base, so the diff below shows only this PR's changes. Merge/land #4 first, then re-target this to master.

Description

Building on the send-amount cap (synonymdev#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: synonymdev#346

Screenshot / Video

QA Notes

Manual Tests

  • 1. Transfer -> Spending Amount: type past Available: amount freezes at the max.
  • 2. Spending Advanced: type past the max LSP balance: capped.
  • 3a. Fund Manual (external node) -> Amount: type past Available: capped.
    • 3b. Fund Manual -> enter an amount above the fundable balance: Continue is disabled (previously enabled).
  • 4. LNURL Pay -> Amount: type past max sendable: capped.
  • 5. LNURL Withdraw -> Amount: type past max withdrawable: capped.
  • 6. regression: Receive / CJIT Amount: no upper cap; any amount can still be entered.

Automated Checks

  • No new unit tests: the cap mechanism is covered by BitkitTests/NumberPadTests.swift (added in fix: cap send amount pad at available balance #4); these screens are view-level wiring plus one button-validation fix, verified by build + manual QA.
  • Built for iOS Simulator (Debug) locally; BitkitTests/NumberPadTests passes (24 tests).
  • Verified on-device (geoblock-off regtest build): Transfer-to-Spending number pad capped at the max transfer amount (see recording); Receive/CJIT confirmed uncapped (minimum only).
  • CI: standard build/test checks run by the PR bot.

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

Copy link
Copy Markdown
Owner Author

Re-opened upstream as synonymdev#585. Closing this fork self-review PR.

@CypherPoet CypherPoet closed this Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant