6 Commits

Include renames

Author	SHA1	Message	Date
sneak	c1ac51d514	fix: the confirmation screen reads its balance on the network it is drawn for (closes #558) ... ConfirmTx showed and checked the balance Send handed it, so a popup reopened onto a confirmation saved before a network switch stated the other network's balance and checked the amount against it. Each time it is shown, ConfirmTx now reads the From address's ETH balance, and for a token send its token balance, from the node of the network it is drawn for, and gives that node to the fee estimate, which starts once the read is done. Until then the balance line says "Loading..." and Sign & Send stays disabled; a failed read is stated as unknown. Each message the read can bring has a box reserved from the first paint, so nothing moves when it returns. Model: opus-5-5	2026-10-19 00:17:07 +00:00
clawbot	1f5ec1c8de	fix: Send refuses every amount the confirmation screen would refuse (closes #532) ... Send's Review accepted any amount parseFloat() read as above zero, so 1e-3, 1abc and amounts with too many decimal places reached ConfirmTx, which then refused them or failed to estimate the fee. isValidAmount() in src/shared/txValidation.js is now the one amount check, used by Send's Review and Max and by validateTransfer() for ConfirmTx: plain digits with at most one decimal point, above zero, nothing but zeros past the token's places. Zeros past those places are accepted, since the transfer encodes the amount exactly. Send now reads the token's decimal places before the ENS lookup, because the check needs them. Judgement call: ConfirmTx now also refuses zero, as Send already did. Model: opus-5-5	2026-10-18 22:46:07 +02:00
clawbot	a207ac70bd	feat: a "Max" button on the Send screen (closes #198) ... Max fills in a token's balance, cut down to the 18 decimal places the confirmation screen accepts, or for ETH the exact balance minus the fee reserve the confirmation screen's balance check gates on. An ETH fee estimate that finishes after the Send screen was left, or its address, holding, recipient or amount changed, fills nothing in. The confirmation screen works a max ETH amount out again from its own fee estimate and signs it with that estimate's fee fields, so a fee that rose before signing cannot push amount plus fee above the balance. validateTransfer() still gates every send, the check that ETH covers a token send's fee included. Where there is nothing to fill in, a flash message says why. Model: opus-5-5	2026-10-05 07:43:06 +02:00
clawbot	467b849a13	fix: show balances and fees below 0.000001 as nonzero on the send screens (closes #343) ... The stored ETH and token balances and the send-confirm screen's fee were each cut to six decimal places, and a token holding cut to zero was dropped, so a value below 0.000001 read as zero. Balances are now stored exactly, whatever decimals a token declares, and every nonzero token holding is kept; the balance check reads a token balance to its first 18 places. The balance lists, the send-screen token selector, the address total and the remove-address warning leave out a holding below 0.000001 themselves, through isBelowOneMillionth(). The send and send-confirm screens' balances, reserve and insufficient-balance messages go through truncateAmountNeverZero(). The send-confirm and approval screens both render the fee through formatFee(), which prices the exact fee in USD. Model: opus-5-5	2026-10-04 11:07:37 +02:00
clawbot	47bf38644d	build: add ESLint to script/lint and containerize linting (closes #152)	2026-08-17 09:10:03 +02:00
clawbot	158278d251	fix: count the network fee in the confirm-screen balance check (closes #154)	2026-08-11 15:41:37 +02:00