checkRecipientHistory() in src/popup/views/confirmTx.js now drops its result when the screen no longer shows the transaction the checks were started for, with the same pendingTx !== txInfo test estimateGas() and readBalances() use. Before, a late answer about the first recipient could make the never-sent-a-transaction, contract or Etherscan phishing box appear on the next recipient's screen.
Tests, in the new tests/confirmTxLateResult.test.js: each holds back the first screen's answer to one question and gives it after the second recipient's screen is shown. They cover each of the three warning boxes, and also the existing checks in readBalances() and estimateGas(), which had no test. For each box a second test gives the answer while its own screen is still shown and expects the box, so the late tests cannot pass merely because the answer shows no box at all.
Not visible in the diff:
The tests are in a new file rather than tests/confirmTxNetworkSwitch.test.js: that file's stub node gives every address the same balance, so no recipient there can hold no ETH, and its header covers the network the screen is drawn for.
The fee test covers the check on the estimate's success path; the one on its failure path is still untested.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/575.
`checkRecipientHistory()` in `src/popup/views/confirmTx.js` now drops its result when the screen no longer shows the transaction the checks were started for, with the same `pendingTx !== txInfo` test `estimateGas()` and `readBalances()` use. Before, a late answer about the first recipient could make the never-sent-a-transaction, contract or Etherscan phishing box appear on the next recipient's screen.
Tests, in the new `tests/confirmTxLateResult.test.js`: each holds back the first screen's answer to one question and gives it after the second recipient's screen is shown. They cover each of the three warning boxes, and also the existing checks in `readBalances()` and `estimateGas()`, which had no test. For each box a second test gives the answer while its own screen is still shown and expects the box, so the late tests cannot pass merely because the answer shows no box at all.
Not visible in the diff:
- The tests are in a new file rather than `tests/confirmTxNetworkSwitch.test.js`: that file's stub node gives every address the same balance, so no recipient there can hold no ETH, and its header covers the network the screen is drawn for.
- The fee test covers the check on the estimate's success path; the one on its failure path is still untested.
Model: opus-5-5
checkRecipientHistory() showed the warning boxes whenever its lookups
answered, so after Back and a review to another recipient, a late answer
about the first recipient could show the never-sent-a-transaction, contract
or Etherscan phishing box on the second recipient's screen. It now drops a
result for a transaction no longer on screen, as estimateGas() and
readBalances() already do.
tests/confirmTxLateResult.test.js holds back the first screen's answer until
the second screen is shown, for each of the three boxes, the balance read and
the fee estimate.
Model: opus-5-5
Passes: a late result of the recipient checks for a transaction the user has left no longer changes any of the three recipient warning boxes on the confirmation screen (contract, never sent a transaction, Etherscan phishing label), as #575 asks, and each box has a test that fails without the fix.
Judgement call: the two added tests of the existing balance read and fee estimate checks cover the same late answer on the same screen, the check the issue names as its model; I took them as within scope.
Not verified: the confirmation screen in a real browser.
Model: opus-5-5
Passes: a late result of the recipient checks for a transaction the user has left no longer changes any of the three recipient warning boxes on the confirmation screen (contract, never sent a transaction, Etherscan phishing label), as https://git.eeqj.de/sneak/AutistMask/issues/575 asks, and each box has a test that fails without the fix.
Judgement call: the two added tests of the existing balance read and fee estimate checks cover the same late answer on the same screen, the check the issue names as its model; I took them as within scope.
Not verified: the confirmation screen in a real browser.
Model: opus-5-5
clawbot
merged commit 20e4f1652f into next2026-10-19 12:27:11 +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.
Fixes #575.
checkRecipientHistory()insrc/popup/views/confirmTx.jsnow drops its result when the screen no longer shows the transaction the checks were started for, with the samependingTx !== txInfotestestimateGas()andreadBalances()use. Before, a late answer about the first recipient could make the never-sent-a-transaction, contract or Etherscan phishing box appear on the next recipient's screen.Tests, in the new
tests/confirmTxLateResult.test.js: each holds back the first screen's answer to one question and gives it after the second recipient's screen is shown. They cover each of the three warning boxes, and also the existing checks inreadBalances()andestimateGas(), which had no test. For each box a second test gives the answer while its own screen is still shown and expects the box, so the late tests cannot pass merely because the answer shows no box at all.Not visible in the diff:
tests/confirmTxNetworkSwitch.test.js: that file's stub node gives every address the same balance, so no recipient there can hold no ETH, and its header covers the network the screen is drawn for.Model: opus-5-5
Passes: a late result of the recipient checks for a transaction the user has left no longer changes any of the three recipient warning boxes on the confirmation screen (contract, never sent a transaction, Etherscan phishing label), as #575 asks, and each box has a test that fails without the fix.
Judgement call: the two added tests of the existing balance read and fee estimate checks cover the same late answer on the same screen, the check the issue names as its model; I took them as within scope.
Not verified: the confirmation screen in a real browser.
Model: opus-5-5