The transaction detail screen decoded a transaction's data against the history entry's to. For a token transfer row that is the transfer's recipient (parseTokenTransfer() in src/shared/transactions.js), not the contract the transaction was sent to. So the decoded Token line named the recipient, and the amount read "decimals unknown" for a token the wallet tracks.
loadFullTxDetails() now decodes against to.hash in the explorer's answer for that transaction, the same answer the data comes from, and no longer takes the history entry's to.
What the diff does not show:
For native and contract-call rows the history entry's to and the explorer's to are the same address, so their decoding is unchanged.
The row's token contract would have been the wrong fix: a swap row carries the token it received as its token contract, but the swap was sent to the router, and the router decoder needs the router's address.
A token transfer that reached you through someone else's call to another contract now decodes against that contract, the one the transaction actually called.
Neither browser suite reaches the decoder: the Chrome suite's explorer stub gives every transaction empty data, and the Firefox suite does not open this screen. The new tests/tokenTransferDetail.test.js covers it: it builds the row with the real history parser and checks the Token, Recipient and Amount lines.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/515.
The transaction detail screen decoded a transaction's data against the history entry's `to`. For a token transfer row that is the transfer's recipient (`parseTokenTransfer()` in `src/shared/transactions.js`), not the contract the transaction was sent to. So the decoded Token line named the recipient, and the amount read "decimals unknown" for a token the wallet tracks.
`loadFullTxDetails()` now decodes against `to.hash` in the explorer's answer for that transaction, the same answer the data comes from, and no longer takes the history entry's `to`.
What the diff does not show:
- For native and contract-call rows the history entry's `to` and the explorer's `to` are the same address, so their decoding is unchanged.
- The row's token contract would have been the wrong fix: a swap row carries the token it received as its token contract, but the swap was sent to the router, and the router decoder needs the router's address.
- A token transfer that reached you through someone else's call to another contract now decodes against that contract, the one the transaction actually called.
- Neither browser suite reaches the decoder: the Chrome suite's explorer stub gives every transaction empty data, and the Firefox suite does not open this screen. The new `tests/tokenTransferDetail.test.js` covers it: it builds the row with the real history parser and checks the Token, Recipient and Amount lines.
Model: opus-5-5
The screen decoded a transaction's data against the history entry's `to`,
which for a token transfer row is the transfer's recipient. The decoded
Token line named the recipient, and the amount read "decimals unknown" for
a token the wallet tracks. It now decodes against the address the
explorer's answer for that transaction says it was sent to, which is the
right address for every kind of row. tests/tokenTransferDetail.test.js
opens a row made by the real history parser and checks the Token,
Recipient and Amount lines.
Model: opus-5-5
PASS: the transaction detail screen now decodes a token transfer against the contract the transaction was sent to, whichever history list opens it, and the new test checks the Token line and the amount at the token's known scale.
Model: opus-5-5
PASS: the transaction detail screen now decodes a token transfer against the contract the transaction was sent to, whichever history list opens it, and the new test checks the Token line and the amount at the token's known scale.
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.
Fixes #515.
The transaction detail screen decoded a transaction's data against the history entry's
to. For a token transfer row that is the transfer's recipient (parseTokenTransfer()insrc/shared/transactions.js), not the contract the transaction was sent to. So the decoded Token line named the recipient, and the amount read "decimals unknown" for a token the wallet tracks.loadFullTxDetails()now decodes againstto.hashin the explorer's answer for that transaction, the same answer the data comes from, and no longer takes the history entry'sto.What the diff does not show:
toand the explorer'stoare the same address, so their decoding is unchanged.tests/tokenTransferDetail.test.jscovers it: it builds the row with the real history parser and checks the Token, Recipient and Amount lines.Model: opus-5-5
PASS: the transaction detail screen now decodes a token transfer against the contract the transaction was sent to, whichever history list opens it, and the new test checks the Token line and the amount at the token's known scale.
Model: opus-5-5