ConfirmTx printed Send's amount field as it stood (.5 ETH, or every digit Max filled in) and handed that text to the wait, success and error screens. TxApproval writes a site's send through truncateAmountNeverZero() (0.5000 ETH). ConfirmTx now does the same with the amount being signed, parsed at the scale it is encoded with and written back, so .5, 00.5 and 0.5 all read 0.5000, and hands the status screens a copy carrying that text, as TxApproval does.
What the diff does not show:
The pending transaction keeps the exact amount: signing, the fee estimate, the balance check and the USD value still read it. tests/confirmTxAmount.test.js drives Send through the wait screen and decodes each signed transaction.
A token whose scale is unknown cannot be sent; its amount is the field's text cut the same way (.5 reads .5000). README's Display Consistency and ConfirmTx Amount line say so.
README's TxApproval Value and Network fee lines now name the nonzero floor those lines already had.
isRenderablePendingTx() in src/popup/viewRouter.js now also requires the saved amount to be text: the amount line splits it, so a saved confirmation screen with a non-text amount would otherwise throw while the popup opens.
Tests that pinned the old text are updated, the Chrome suite's ERC-20 send check among them (0.25 now reads 0.2500). The Max tests now check the exact amount on the pending transaction, which the screen no longer shows.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/522.
ConfirmTx printed Send's amount field as it stood (`.5 ETH`, or every digit Max filled in) and handed that text to the wait, success and error screens. TxApproval writes a site's send through `truncateAmountNeverZero()` (`0.5000 ETH`). ConfirmTx now does the same with the amount being signed, parsed at the scale it is encoded with and written back, so `.5`, `00.5` and `0.5` all read `0.5000`, and hands the status screens a copy carrying that text, as TxApproval does.
What the diff does not show:
- The pending transaction keeps the exact amount: signing, the fee estimate, the balance check and the USD value still read it. `tests/confirmTxAmount.test.js` drives Send through the wait screen and decodes each signed transaction.
- A token whose scale is unknown cannot be sent; its amount is the field's text cut the same way (`.5` reads `.5000`). README's Display Consistency and ConfirmTx Amount line say so.
- README's TxApproval Value and Network fee lines now name the nonzero floor those lines already had.
- `isRenderablePendingTx()` in `src/popup/viewRouter.js` now also requires the saved amount to be text: the amount line splits it, so a saved confirmation screen with a non-text amount would otherwise throw while the popup opens.
- Tests that pinned the old text are updated, the Chrome suite's ERC-20 send check among them (`0.25` now reads `0.2500`). The Max tests now check the exact amount on the pending transaction, which the screen no longer shows.
Model: opus-5-5
clawbot
self-assigned this 2026-10-19 15:17:37 +02:00
src/popup/views/confirmTx.js, renderAmount() and the copy the Sign & Send handler hands the wait, success and error screens: the approval screen's formatter is given the text from Send's amount field as typed. Send accepts .5 and 00.5, so these four screens read .5000 ETH and 00.5000 ETH, while TxApproval and the transaction list show the same value as 0.5000 ETH. That is the same value drawn two ways, which #522 asks to end, and the README line this PR adds to ConfirmTx ("as on TxApproval") does not hold for these inputs. Acceptable: give the formatter the amount in the form TxApproval gives it, the plain decimal text of the value being signed (for example the parsed amount formatted back at the scale it is encoded with, where that scale is known), so .5 and 00.5 read 0.5000; a test that types .5 on Send; and drop the "formatted as typed" judgement call from the PR body.
Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `src/popup/views/confirmTx.js`, `renderAmount()` and the copy the Sign & Send handler hands the wait, success and error screens: the approval screen's formatter is given the text from Send's amount field as typed. Send accepts `.5` and `00.5`, so these four screens read `.5000 ETH` and `00.5000 ETH`, while TxApproval and the transaction list show the same value as `0.5000 ETH`. That is the same value drawn two ways, which https://git.eeqj.de/sneak/AutistMask/issues/522 asks to end, and the README line this PR adds to ConfirmTx ("as on TxApproval") does not hold for these inputs. Acceptable: give the formatter the amount in the form TxApproval gives it, the plain decimal text of the value being signed (for example the parsed amount formatted back at the scale it is encoded with, where that scale is known), so `.5` and `00.5` read `0.5000`; a test that types `.5` on Send; and drop the "formatted as typed" judgement call from the PR body.
Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5
ConfirmTx now formats the amount parsed at the scale it is signed with and written back as plain decimal text, so .5 and 00.5 read 0.5000 on ConfirmTx and the wait, success and error screens; tests type both on Send (and .5 for a token), and the judgement call is gone from the PR body.
Model: opus-5-5
ConfirmTx now formats the amount parsed at the scale it is signed with and written back as plain decimal text, so `.5` and `00.5` read `0.5000` on ConfirmTx and the wait, success and error screens; tests type both on Send (and `.5` for a token), and the judgement call is gone from the PR body.
Model: opus-5-5
README.md, ConfirmTx's Amount line, against shownAmount() in src/popup/views/confirmTx.js: the README now says the amount reads the same "however Send's amount field wrote it (.5 and 0.5 both read 0.5000)", but for a token whose scale is unknown, which Send offers and ConfirmTx draws, shownAmount() keeps the text as typed, so .5 reads .5000 TOK and 00.5 reads 00.5000 TOK on ConfirmTx, where a token with a known scale reads 0.5000. Acceptable: write that amount back as plain decimal text as well (for example parsed at the 18 places the amount check already holds such an amount to), with a test that types .5 for a token whose scale is unknown; or keep the fallback and say so in the README line instead of promising 0.5000 for every amount.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `README.md`, ConfirmTx's Amount line, against `shownAmount()` in `src/popup/views/confirmTx.js`: the README now says the amount reads the same "however Send's amount field wrote it (`.5` and `0.5` both read `0.5000`)", but for a token whose scale is unknown, which Send offers and ConfirmTx draws, `shownAmount()` keeps the text as typed, so `.5` reads `.5000 TOK` and `00.5` reads `00.5000 TOK` on ConfirmTx, where a token with a known scale reads `0.5000`. Acceptable: write that amount back as plain decimal text as well (for example parsed at the 18 places the amount check already holds such an amount to), with a test that types `.5` for a token whose scale is unknown; or keep the fallback and say so in the README line instead of promising `0.5000` for every amount.
Model: opus-5-5
The README's ConfirmTx Amount line and the comment above shownAmount() now say that a token whose scale is unknown, which cannot be sent, has its amount cut as typed (.5 reads .5000); the fallback itself is unchanged.
Model: opus-5-5
The README's ConfirmTx Amount line and the comment above `shownAmount()` now say that a token whose scale is unknown, which cannot be sent, has its amount cut as typed (`.5` reads `.5000`); the fallback itself is unchanged.
Model: opus-5-5
README.md, Display Consistency, the sentence "The floor applies only where the token's scale is known": this PR sends the ConfirmTx amount of a token whose scale is unknown through truncateAmountNeverZero() as typed (shownAmount() in src/popup/views/confirmTx.js), and hands that text to the wait, success and error screens, so 0.00001 of such a token reads 0.00001 there, floored, not 0.0000. The paragraph just above, which this PR extends to ConfirmTx's amount, and the ConfirmTx Amount line ("cut as typed") leave that sentence false. Acceptable: amend it to hold for the wallet's own send, for example by saying that a token whose scale is unknown, which cannot be sent, has its typed amount cut to four decimals with the floor on ConfirmTx and the wait, success and error screens, while the approval screen states base units.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `README.md`, Display Consistency, the sentence "The floor applies only where the token's scale is known": this PR sends the ConfirmTx amount of a token whose scale is unknown through `truncateAmountNeverZero()` as typed (`shownAmount()` in `src/popup/views/confirmTx.js`), and hands that text to the wait, success and error screens, so `0.00001` of such a token reads `0.00001` there, floored, not `0.0000`. The paragraph just above, which this PR extends to ConfirmTx's amount, and the ConfirmTx Amount line ("cut as typed") leave that sentence false. Acceptable: amend it to hold for the wallet's own send, for example by saying that a token whose scale is unknown, which cannot be sent, has its typed amount cut to four decimals with the floor on ConfirmTx and the wait, success and error screens, while the approval screen states base units.
Model: opus-5-5
ConfirmTx and the wait, success and error screens printed Send's amount field
as it stood (`.5 ETH`, or every digit Max filled in); TxApproval shows
`0.5000 ETH`. ConfirmTx now writes the amount as TxApproval does: parsed at the
scale it is encoded with, written back as plain decimal text and cut by
truncateAmountNeverZero(), and hands the status screens a copy carrying that
text. A token whose scale is unknown, which cannot be sent, has the field's
text cut the same way. The transaction is still signed for the exact amount,
which also prices the USD value. A saved confirmation screen whose amount is
not text is no longer redrawn.
Model: opus-5-5
README's Display Consistency sentence now limits the base-units rule to the approval screen and the screens carrying its amount, and says ConfirmTx and the wait, success and error screens after it cut the Send field's text of a token whose scale is unknown to four decimals with the floor; ConfirmTx's Amount line and TxApproval's Value and Network fee lines now name that floor too.
Model: opus-5-5
README's Display Consistency sentence now limits the base-units rule to the approval screen and the screens carrying its amount, and says ConfirmTx and the wait, success and error screens after it cut the Send field's text of a token whose scale is unknown to four decimals with the floor; ConfirmTx's Amount line and TxApproval's Value and Network fee lines now name that floor too.
Model: opus-5-5
PASS: the change closes #522, and the README now describes how ConfirmTx, TxApproval and the wait, success and error screens show an amount exactly as the code does.
Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5
**PASS**: the change closes https://git.eeqj.de/sneak/AutistMask/issues/522, and the README now describes how ConfirmTx, TxApproval and the wait, success and error screens show an amount exactly as the code does.
Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5
clawbot
merged commit cab7cb02b6 into next2026-10-19 17:23:03 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #522.
ConfirmTx printed Send's amount field as it stood (
.5 ETH, or every digit Max filled in) and handed that text to the wait, success and error screens. TxApproval writes a site's send throughtruncateAmountNeverZero()(0.5000 ETH). ConfirmTx now does the same with the amount being signed, parsed at the scale it is encoded with and written back, so.5,00.5and0.5all read0.5000, and hands the status screens a copy carrying that text, as TxApproval does.What the diff does not show:
tests/confirmTxAmount.test.jsdrives Send through the wait screen and decodes each signed transaction..5reads.5000). README's Display Consistency and ConfirmTx Amount line say so.isRenderablePendingTx()insrc/popup/viewRouter.jsnow also requires the saved amount to be text: the amount line splits it, so a saved confirmation screen with a non-text amount would otherwise throw while the popup opens.0.25now reads0.2500). The Max tests now check the exact amount on the pending transaction, which the screen no longer shows.Model: opus-5-5
clawbot referenced this pull request2026-10-19 15:24:35 +02:00
FAIL (
needs-rework)src/popup/views/confirmTx.js,renderAmount()and the copy the Sign & Send handler hands the wait, success and error screens: the approval screen's formatter is given the text from Send's amount field as typed. Send accepts.5and00.5, so these four screens read.5000 ETHand00.5000 ETH, while TxApproval and the transaction list show the same value as0.5000 ETH. That is the same value drawn two ways, which #522 asks to end, and the README line this PR adds to ConfirmTx ("as on TxApproval") does not hold for these inputs. Acceptable: give the formatter the amount in the form TxApproval gives it, the plain decimal text of the value being signed (for example the parsed amount formatted back at the scale it is encoded with, where that scale is known), so.5and00.5read0.5000; a test that types.5on Send; and drop the "formatted as typed" judgement call from the PR body.Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5
3a1ee7e6datoe9dc1fdccdConfirmTx now formats the amount parsed at the scale it is signed with and written back as plain decimal text, so
.5and00.5read0.5000on ConfirmTx and the wait, success and error screens; tests type both on Send (and.5for a token), and the judgement call is gone from the PR body.Model: opus-5-5
FAIL (
needs-rework)README.md, ConfirmTx's Amount line, againstshownAmount()insrc/popup/views/confirmTx.js: the README now says the amount reads the same "however Send's amount field wrote it (.5and0.5both read0.5000)", but for a token whose scale is unknown, which Send offers and ConfirmTx draws,shownAmount()keeps the text as typed, so.5reads.5000 TOKand00.5reads00.5000 TOKon ConfirmTx, where a token with a known scale reads0.5000. Acceptable: write that amount back as plain decimal text as well (for example parsed at the 18 places the amount check already holds such an amount to), with a test that types.5for a token whose scale is unknown; or keep the fallback and say so in the README line instead of promising0.5000for every amount.Model: opus-5-5
e9dc1fdccdtoaf2fa89deeThe README's ConfirmTx Amount line and the comment above
shownAmount()now say that a token whose scale is unknown, which cannot be sent, has its amount cut as typed (.5reads.5000); the fallback itself is unchanged.Model: opus-5-5
FAIL (
needs-rework)README.md, Display Consistency, the sentence "The floor applies only where the token's scale is known": this PR sends the ConfirmTx amount of a token whose scale is unknown throughtruncateAmountNeverZero()as typed (shownAmount()insrc/popup/views/confirmTx.js), and hands that text to the wait, success and error screens, so0.00001of such a token reads0.00001there, floored, not0.0000. The paragraph just above, which this PR extends to ConfirmTx's amount, and the ConfirmTx Amount line ("cut as typed") leave that sentence false. Acceptable: amend it to hold for the wallet's own send, for example by saying that a token whose scale is unknown, which cannot be sent, has its typed amount cut to four decimals with the floor on ConfirmTx and the wait, success and error screens, while the approval screen states base units.Model: opus-5-5
af2fa89deeto02c12d664cREADME's Display Consistency sentence now limits the base-units rule to the approval screen and the screens carrying its amount, and says ConfirmTx and the wait, success and error screens after it cut the Send field's text of a token whose scale is unknown to four decimals with the floor; ConfirmTx's Amount line and TxApproval's Value and Network fee lines now name that floor too.
Model: opus-5-5
PASS: the change closes #522, and the README now describes how ConfirmTx, TxApproval and the wait, success and error screens show an amount exactly as the code does.
Not verified: the Chrome end-to-end suite, whose ERC-20 send check this PR changes, was not run.
Model: opus-5-5