sneak/AutistMask
1
0
Fork 0
Code Issues 26 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix: the send and send-confirm screens render a sub-1e-6 balance and fee as 0.0 #343

New Issue
Closed
opened 2026-08-23 15:38:21 +02:00 by clawbot · 2 comments
clawbot commented 2026-08-23 15:38:21 +02:00
Collaborator
Copy Link
Copy Source

Found by the re-review of #339 (#339 (comment)). Pre-existing; not introduced there.

src/shared/balances.js:31,39 and src/popup/views/confirmTx.js:299 (formatFeeEth) use a 6-decimal truncation, separate from the 4-decimal rule that #322 fixed. A quantity below 1e-6 renders as 0.0 — visible as Current balance on the send screen, and Balance plus the fee line on the send-confirm screen.

Same failure mode as #322: a nonzero quantity displayed as nothing. The direct consequence of that issue's fix is an inconsistency the repo's own Display Consistency rule forbids — the approval screen's max fee is now floored while the send-confirm screen's fee is not, so the same value renders differently on two screens.

Deliberately NOT in milestone 1.0.0, and the reasoning should be re-examined rather than inherited: unlike the approval-screen case, the understatement here is bounded at 1e-6, these are balance and fee readouts rather than the figure the user is authorizing, and at 6 decimals the hidden quantity is dust for any realistic token. Promote it if that judgement is wrong.

Definition of done

  • A nonzero balance or fee never renders as 0.0 on the send or send-confirm screens.
  • The fee is rendered consistently on the send-confirm and approval screens — same value, same string. Prefer routing both through the shared helper in src/shared/amountDisplay.js over adding a fourth truncation rule.
  • Test: a sub-1e-6 balance and a sub-1e-6 fee each render nonzero. Fails against current head — state the mutation and observed result.
  • make check green.
Found by the re-review of https://git.eeqj.de/sneak/AutistMask/pulls/339 (https://git.eeqj.de/sneak/AutistMask/pulls/339#issuecomment-69037). Pre-existing; not introduced there. `src/shared/balances.js:31,39` and `src/popup/views/confirmTx.js:299` (`formatFeeEth`) use a **6-decimal** truncation, separate from the 4-decimal rule that https://git.eeqj.de/sneak/AutistMask/issues/322 fixed. A quantity below 1e-6 renders as `0.0` — visible as `Current balance` on the send screen, and `Balance` plus the fee line on the send-confirm screen. Same failure mode as https://git.eeqj.de/sneak/AutistMask/issues/322: a nonzero quantity displayed as nothing. The direct consequence of that issue's fix is an inconsistency the repo's own Display Consistency rule forbids — **the approval screen's max fee is now floored while the send-confirm screen's fee is not**, so the same value renders differently on two screens. Deliberately NOT in milestone 1.0.0, and the reasoning should be re-examined rather than inherited: unlike the approval-screen case, the understatement here is bounded at 1e-6, these are balance and fee readouts rather than the figure the user is authorizing, and at 6 decimals the hidden quantity is dust for any realistic token. Promote it if that judgement is wrong. ## Definition of done - [ ] A nonzero balance or fee never renders as `0.0` on the send or send-confirm screens. - [ ] The fee is rendered consistently on the send-confirm and approval screens — same value, same string. Prefer routing both through the shared helper in `src/shared/amountDisplay.js` over adding a fourth truncation rule. - [ ] Test: a sub-1e-6 balance and a sub-1e-6 fee each render nonzero. Fails against current head — state the mutation and observed result. - [ ] `make check` green.
clawbot added this to the 1.0.0 milestone 2026-09-21 09:20:00 +02:00
clawbot commented 2026-10-03 14:18:59 +02:00
Author
Collaborator
Copy Link
Copy Source

Plan. In milestone 1.0.0, so it is fixed now. One PR on a branch cut from next, base next.

  • Route the send screen's Current balance, and the send-confirm screen's Balance and fee, through the shared display helper in src/shared/amountDisplay.js that the approval screen already uses, and remove the separate 6-decimal truncation in src/shared/balances.js and formatFeeEth in src/popup/views/confirmTx.js if nothing else needs it.
  • The same fee value renders as the same string on the send-confirm and approval screens.
  • Unit tests: a sub-1e-6 balance and a sub-1e-6 fee each render nonzero; each fails against current next.
  • #377 and #372 touch the same screens and follow this unit.

Model: opus-5-5

Plan. In milestone 1.0.0, so it is fixed now. One PR on a branch cut from `next`, base `next`. - Route the send screen's `Current balance`, and the send-confirm screen's `Balance` and fee, through the shared display helper in `src/shared/amountDisplay.js` that the approval screen already uses, and remove the separate 6-decimal truncation in `src/shared/balances.js` and `formatFeeEth` in `src/popup/views/confirmTx.js` if nothing else needs it. - The same fee value renders as the same string on the send-confirm and approval screens. - Unit tests: a sub-1e-6 balance and a sub-1e-6 fee each render nonzero; each fails against current `next`. - https://git.eeqj.de/sneak/AutistMask/issues/377 and https://git.eeqj.de/sneak/AutistMask/issues/372 touch the same screens and follow this unit. Model: opus-5-5
clawbot commented 2026-10-04 04:09:35 +02:00
Author
Collaborator
Copy Link
Copy Source

Done in #417. The ETH balance is now stored exactly. The send screen's balance, and the send-confirm screen's balance, fee and reserve, use the same display helper as the approval screen, so the same fee reads the same on both. Token balances keep their six-decimal stored value, because it also decides which dust holdings are left off the balance list.

Model: opus-5-5

Done in https://git.eeqj.de/sneak/AutistMask/pulls/417. The ETH balance is now stored exactly. The send screen's balance, and the send-confirm screen's balance, fee and reserve, use the same display helper as the approval screen, so the same fee reads the same on both. Token balances keep their six-decimal stored value, because it also decides which dust holdings are left off the balance list. Model: opus-5-5
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
critical
Extremely important: data loss, a security hole, production down, or basic use impossible
 merge-ready
needs-checks
needs-rebase
needs-review
needs-rework
No labels
Milestone
No items
No Milestone 1.0.0
Projects
Clear projects
No projects
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/AutistMask#343