Send's "Review" accepted any amount parseFloat() read as above zero, so 1e-3, 1abc and amounts with too many decimal places reached ConfirmTx. There, 1e-3, 1abc and a nonzero digit past the 18th place got "Please enter a valid amount to send." with Sign & Send disabled, while a token amount with a nonzero digit past the token's own places got only "The network fee could not be estimated".
isValidAmount() in src/shared/txValidation.js is now the one amount check. Send's "Review" and "Max" call it with the token's decimal places, and validateTransfer() calls it for ConfirmTx, which now says such a token amount is not valid. An amount passes when it is a number above zero, written as digits with at most one decimal point, with nothing but zeros after the token's last decimal place or after the 18th. A token whose decimal places are unknown is held to 18, so it still reaches ConfirmTx, which says why it cannot be sent.
Not obvious from the diff:
Zeros past the token's places are accepted on both screens: the transfer encodes 1.0000000 of a 6-place token as exactly 1.
Send's Review handler now reads the token's decimal places, symbol and balance before the ENS lookup, not after, because the amount check needs the decimal places.
New test file tests/sendAmountRule.test.js drives the real Send review handler and ConfirmTx.
Judgement call: ConfirmTx now also refuses zero, which Send already refused, because the issue asks for one rule.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/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. There, `1e-3`, `1abc` and a nonzero digit past the 18th place got "Please enter a valid amount to send." with Sign & Send disabled, while a token amount with a nonzero digit past the token's own places got only "The network fee could not be estimated".
`isValidAmount()` in `src/shared/txValidation.js` is now the one amount check. Send's "Review" and "Max" call it with the token's decimal places, and `validateTransfer()` calls it for ConfirmTx, which now says such a token amount is not valid. An amount passes when it is a number above zero, written as digits with at most one decimal point, with nothing but zeros after the token's last decimal place or after the 18th. A token whose decimal places are unknown is held to 18, so it still reaches ConfirmTx, which says why it cannot be sent.
Not obvious from the diff:
- Zeros past the token's places are accepted on both screens: the transfer encodes `1.0000000` of a 6-place token as exactly 1.
- Send's Review handler now reads the token's decimal places, symbol and balance before the ENS lookup, not after, because the amount check needs the decimal places.
New test file `tests/sendAmountRule.test.js` drives the real Send review handler and ConfirmTx.
Judgement call: ConfirmTx now also refuses zero, which Send already refused, because the issue asks for one rule.
Model: opus-5-5
README.md lines 1689-1692 and the comment above isValidAmount() in src/shared/txValidation.js (lines 91-98) say an amount with more decimal places than the token has is refused. The check still accepts one when the extra places are all zeros: 1.0000000 passes for a 6-place token, and 1.0000000000000000000 passes for ETH, on Send and on ConfirmTx alike. The PR body says the same thing. Acceptable: either the README sentence and the comment say that trailing zeros past the token's places are allowed, or isValidAmount() refuses them and a test covers that entry.
Model: opus-5-5
Review failed.
1. `README.md` lines 1689-1692 and the comment above `isValidAmount()` in `src/shared/txValidation.js` (lines 91-98) say an amount with more decimal places than the token has is refused. The check still accepts one when the extra places are all zeros: `1.0000000` passes for a 6-place token, and `1.0000000000000000000` passes for ETH, on Send and on ConfirmTx alike. The PR body says the same thing. Acceptable: either the README sentence and the comment say that trailing zeros past the token's places are allowed, or `isValidAmount()` refuses them and a test covers that entry.
Model: opus-5-5
Send accepted any amount parseFloat() read as above zero, so "1e-3",
"1abc" and an amount with a nonzero digit past the token's decimal places
reached ConfirmTx, which then refused them. isValidAmount() in
src/shared/txValidation.js is now the one check: Review and Max on Send
call it with the token's decimal places, and validateTransfer() calls it
for ConfirmTx, which now also refuses a zero amount and a token amount
with a nonzero digit past the token's places. Zeros past those places
are accepted, since the amount encoded for the transfer is the same.
Model: opus-5-5
Kept accepting zeros past the token's places, since the transfer is encoded as the amount typed. The README sentence, the comment above isValidAmount() and the PR body now say so, and new tests cover 1.0000000 for a 6-place token and 0.5000000000000000000 ETH on both screens, plus the token transfer encoding it as exactly 1.
Model: opus-5-5
1. Kept accepting zeros past the token's places, since the transfer is encoded as the amount typed. The README sentence, the comment above `isValidAmount()` and the PR body now say so, and new tests cover `1.0000000` for a 6-place token and `0.5000000000000000000` ETH on both screens, plus the token transfer encoding it as exactly 1.
Model: opus-5-5
PR body: it runs to about 280 words, over the limit of about 250. Its first paragraph also says ConfirmTx refused all three entries with "Please enter a valid amount to send.", but its third bullet says, correctly, that ConfirmTx reported a token amount with a nonzero digit past the token's places only as a network fee that could not be estimated. Acceptable: a body of about 250 words or fewer whose account of the old behaviour agrees with itself, for example by dropping the README bullet and the sentence naming the new test file's directory.
Model: opus-5-5
Review failed.
1. PR body: it runs to about 280 words, over the limit of about 250. Its first paragraph also says ConfirmTx refused all three entries with "Please enter a valid amount to send.", but its third bullet says, correctly, that ConfirmTx reported a token amount with a nonzero digit past the token's places only as a network fee that could not be estimated. Acceptable: a body of about 250 words or fewer whose account of the old behaviour agrees with itself, for example by dropping the README bullet and the sentence naming the new test file's directory.
Model: opus-5-5
Rewrote the PR body to under 250 words: its first paragraph now says ConfirmTx refused 1e-3, 1abc and a nonzero digit past the 18th place as not valid, and a token amount with a nonzero digit past the token's own places only as a fee that could not be estimated. The README bullet is gone; the new test file's path stays because the brief asks for every new file's directory. Code and commit unchanged.
Model: opus-5-5
1. Rewrote the PR body to under 250 words: its first paragraph now says ConfirmTx refused `1e-3`, `1abc` and a nonzero digit past the 18th place as not valid, and a token amount with a nonzero digit past the token's own places only as a fee that could not be estimated. The README bullet is gone; the new test file's path stays because the brief asks for every new file's directory. Code and commit unchanged.
Model: opus-5-5
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 #532.
Send's "Review" accepted any amount
parseFloat()read as above zero, so1e-3,1abcand amounts with too many decimal places reached ConfirmTx. There,1e-3,1abcand a nonzero digit past the 18th place got "Please enter a valid amount to send." with Sign & Send disabled, while a token amount with a nonzero digit past the token's own places got only "The network fee could not be estimated".isValidAmount()insrc/shared/txValidation.jsis now the one amount check. Send's "Review" and "Max" call it with the token's decimal places, andvalidateTransfer()calls it for ConfirmTx, which now says such a token amount is not valid. An amount passes when it is a number above zero, written as digits with at most one decimal point, with nothing but zeros after the token's last decimal place or after the 18th. A token whose decimal places are unknown is held to 18, so it still reaches ConfirmTx, which says why it cannot be sent.Not obvious from the diff:
1.0000000of a 6-place token as exactly 1.New test file
tests/sendAmountRule.test.jsdrives the real Send review handler and ConfirmTx.Judgement call: ConfirmTx now also refuses zero, which Send already refused, because the issue asks for one rule.
Model: opus-5-5
Review failed.
README.mdlines 1689-1692 and the comment aboveisValidAmount()insrc/shared/txValidation.js(lines 91-98) say an amount with more decimal places than the token has is refused. The check still accepts one when the extra places are all zeros:1.0000000passes for a 6-place token, and1.0000000000000000000passes for ETH, on Send and on ConfirmTx alike. The PR body says the same thing. Acceptable: either the README sentence and the comment say that trailing zeros past the token's places are allowed, orisValidAmount()refuses them and a test covers that entry.Model: opus-5-5
1452d3c4d7to75a24b59e7isValidAmount()and the PR body now say so, and new tests cover1.0000000for a 6-place token and0.5000000000000000000ETH on both screens, plus the token transfer encoding it as exactly 1.Model: opus-5-5
Review failed.
Model: opus-5-5
1e-3,1abcand a nonzero digit past the 18th place as not valid, and a token amount with a nonzero digit past the token's own places only as a fee that could not be estimated. The README bullet is gone; the new test file's path stays because the brief asks for every new file's directory. Code and commit unchanged.Model: opus-5-5
Review passed.
Model: opus-5-5