sneak
8fadc4107f
The wallet's own Send screen renders the amount, the balance and the symbol from the block explorer's cached decimals, but confirmTx encoded the transfer from decimals() read off the contract at signing time and nothing compared the two. A token whose on-chain scale disagrees with the cached one -- an upgradeable or proxy token, a caller-dependent one, a stale or wrong explorer entry, a compromised Blockscout -- therefore signed an amount that was never displayed, off by a power of ten for every decimal place of disagreement. The reproduction on the issue approves 0.25 and signs 250,000,000,000. The scale is now carried forward on the pending transaction, taken from the same tokenBalances entry the screen's own numbers come from, and the contract's decimals() is read at signing time only to be compared with it. A disagreement is a refusal that names both numbers, never a preference for either: both candidate transfers move an amount nobody approved. New src/shared/transferAmount.js holds that check, as the confirmTx counterpart to approvalVerify.js, and takes the same stance on an absent or unusable value -- a quantity that cannot be compared with what was displayed has not been checked. The gas estimate encodes from the same carried value and no longer reads decimals() at all, so the estimate is for the transfer that would be signed. Nothing in the e2e suite had ever clicked #btn-confirm-send, so the popup's own Send -> ConfirmTx -> Sign & Send -> WaitTx path had no coverage at all, which is how this shipped. It is now driven end to end to a broadcast, with the transfer() amount hand-decoded out of the raw signed bytes and asserted against the amount read off the confirmation screen, plus a case where the fixture's decimals() starts answering 18 after the screen was built and nothing reaches eth_sendRawTransaction. The fixture gains that override and a receipt, so the wait screen resolves to the success view instead of polling for the rest of the run.
31 KiB
31 KiB