5 Commits

Include renames

Author	SHA1	Message	Date
sneak	db0d81e78e	fix: a popup save no longer undoes a network switch the background saved during it (closes #641) ... The popup's saveState() and the background's updateState() each read the stored record, change it and write it back, and each was ordered only within its own context, so a write by one could land between the other's read and write and be lost. Both now hold the browser's lock (navigator.locks, shared by every page and the background except a page in a Firefox private window) from the read to the write, through withLock() in src/shared/browserApi.js; the recovery screen's reset takes it too. The lock also orders a page's own saves, so both per-context queues are gone. The unit tests get a small lock from a Jest setup file. Model: opus-5-5	2026-10-20 16:58:12 +00:00
clawbot	5e4b8ff3b0	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 screen the popup reopened onto stated the balance as Send knew it, not as it is on the network the screen is drawn for. 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 reviewedNetworkProvider() picks for the network the transaction was reviewed for, the node the fee estimate and recipient checks ask. The fee estimate starts once the read returns. 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 09:54:09 +02:00
clawbot	45f11ee920	fix: say an unknown-scale balance the same way on Send and on confirm (closes #377) ... When two addresses' explorer reports disagree on a token's decimals, the Send screen showed the stored figure while the confirmation screen said the balance was unknown. One function in send.js now gives both the balance and scale, so both read `unknown (SYMBOL)`. The confirmation screen's fee-unknown message names its cause: for an unknown scale it says the wallet does not know the token's decimal places and the transaction cannot be sent, instead of asking for a retry that cannot help. Other causes keep the old sentence. Model: opus-5-5	2026-10-04 15:59:15 +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	1b52aa1723	fix: store an absent explorer decimals as unknown instead of fabricating 18 (closes #349) ... parseInt(decimals || "18") ran before writing stored tokenBalances[].decimals, so an explorer reporting no decimals produced a fabricated 18 indistinguishable from a real one at read time. That defeated the resolve-or-refuse guarantees of #306 and #340: their refusal paths were intact but never fired, because the guess was laundered upstream of them. An absent scale is now stored as unknown, and a holding whose scale nothing knows carries a null balance -- unknown, never zero -- with six reader sites saying so rather than printing 0.0000. The Send screen resolves the display scale rather than reading the stored one, so a bundled token whose explorer row omits decimals still sends; when the scale cannot be resolved the stored quantity is withdrawn too, so the user is told the balance is unknown rather than only that the fee failed. Existing fabricated 18s cannot be told apart retroactively and are replaced wholesale on the next balance refresh. An explorer-sourced scale stays trusted -- only fabrication is removed; the reasoning is recorded on the issue.	2026-08-23 21:19:04 +02:00