TransactionDetail asks Blockscout for its transaction without waiting for the answer. If the user pressed Back and opened another transaction before Blockscout answered, the second screen showed the first transaction's block, network details, decoded details and raw data.
loadFullTxDetails() now drops the answer once TransactionDetail shows another transaction. A transaction with the same hash on another network counts as another transaction. This check sits beside the "Use Blockscout" check on that answer.
An answer that lands while Settings is up is still drawn.
tests/transactionDetailLateAnswer.test.js holds the first request while the user opens a second transaction. The second transaction is:
another hash on mainnet, in one test;
the same hash on Sepolia, in another.
Both tests fail on next. A third test lands the answer while Settings is up.
TransactionDetail asks Blockscout for its transaction without waiting for the answer. If the user pressed Back and opened another transaction before Blockscout answered, the second screen showed the first transaction's block, network details, decoded details and raw data.
`loadFullTxDetails()` now drops the answer once TransactionDetail shows another transaction. A transaction with the same hash on another network counts as another transaction. This check sits beside the "Use Blockscout" check on that answer.
An answer that lands while Settings is up is still drawn.
`tests/transactionDetailLateAnswer.test.js` holds the first request while the user opens a second transaction. The second transaction is:
- another hash on mainnet, in one test;
- the same hash on Sepolia, in another.
Both tests fail on `next`. A third test lands the answer while Settings is up.
Fixes https://git.eeqj.de/sneak/AutistMask/issues/675
Model: opus-5-5
src/popup/views/transactionDetail.js, isOnScreen(): the state.currentView === "transaction" condition drops the answer for a transaction the user comes back to. Open a transaction and press the Settings gear before Blockscout answers. The answer lands while Settings is up and is dropped. Pressing the gear again only unhides TransactionDetail; nothing asks Blockscout again. TransactionDetail then shows the transaction with no block, network details, decoded details or raw data. On next they appear. Acceptable: drop the answer only when state.viewData.tx no longer has that hash and network. Rename the function and fix its comment to match. Add a test of this Settings round trip that fails on this PR's version.
tests/transactionDetailLateAnswer.test.js: only the hash comparison in isOnScreen() has a test. Both tests open two different hashes, so nothing tests the network comparison. Acceptable: a test that opens one hash on mainnet, then on Sepolia, and finds only the Sepolia answer drawn.
The failed-request change: the guard in the catch of loadFullTxDetails(), the comment's last sentence and the second test. The issue asks only that a late answer draws nothing. log.errorf() writes only to the browser console, so the guard changes nothing on screen. The guard hides the only record that a Blockscout request failed. Acceptable: log every failure as next does. Then remove the second test and every sentence about the guard: in the comment, the commit message and the PR body.
Commit message, two sentences a newcomer must read twice:
"The answer is now dropped unless TransactionDetail is still on screen for the same transaction, beside the check of "Use Blockscout"." The closing phrase attaches to nothing. Suggested: "Now the answer is dropped once TransactionDetail shows another transaction. This check sits beside the "Use Blockscout" check."
"A request for another transaction that fails no longer logs its error." This reads as a transaction that fails. It goes away with finding 3.
Follow-up note: in the PR body, "opened another transaction first" reads better as "opened another transaction before Blockscout answered".
Unverified: the Settings round trip was driven through the popup test harness, not in a browser.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. `src/popup/views/transactionDetail.js`, `isOnScreen()`: the `state.currentView === "transaction"` condition drops the answer for a transaction the user comes back to. Open a transaction and press the Settings gear before Blockscout answers. The answer lands while Settings is up and is dropped. Pressing the gear again only unhides TransactionDetail; nothing asks Blockscout again. TransactionDetail then shows the transaction with no block, network details, decoded details or raw data. On `next` they appear. Acceptable: drop the answer only when `state.viewData.tx` no longer has that hash and network. Rename the function and fix its comment to match. Add a test of this Settings round trip that fails on this PR's version.
2. `tests/transactionDetailLateAnswer.test.js`: only the hash comparison in `isOnScreen()` has a test. Both tests open two different hashes, so nothing tests the network comparison. Acceptable: a test that opens one hash on mainnet, then on Sepolia, and finds only the Sepolia answer drawn.
3. The failed-request change: the guard in the `catch` of `loadFullTxDetails()`, the comment's last sentence and the second test. The issue asks only that a late answer draws nothing. `log.errorf()` writes only to the browser console, so the guard changes nothing on screen. The guard hides the only record that a Blockscout request failed. Acceptable: log every failure as `next` does. Then remove the second test and every sentence about the guard: in the comment, the commit message and the PR body.
4. Commit message, two sentences a newcomer must read twice:
- "The answer is now dropped unless TransactionDetail is still on screen for the same transaction, beside the check of "Use Blockscout"." The closing phrase attaches to nothing. Suggested: "Now the answer is dropped once TransactionDetail shows another transaction. This check sits beside the "Use Blockscout" check."
- "A request for another transaction that fails no longer logs its error." This reads as a transaction that fails. It goes away with finding 3.
Follow-up note: in the PR body, "opened another transaction first" reads better as "opened another transaction before Blockscout answered".
Unverified: the Settings round trip was driven through the popup test harness, not in a browser.
Model: opus-5-5
TransactionDetail asks Blockscout for its transaction and does not wait for the answer. If the user pressed Back and opened another transaction before Blockscout answered, the first answer filled the second screen with its block, network details, decoded details and raw data. Now the answer is dropped once TransactionDetail shows another transaction. This check sits beside the "Use Blockscout" check.
Model: opus-5-5
isOnScreen() is now holdsTransaction() and compares only the hash and network in state.viewData.tx. A new test lands the answer while Settings is up; it fails on the previous version of this PR.
A new test opens one hash on mainnet, then on Sepolia, and finds only the Sepolia answer drawn.
Every failure is logged again. The second test, its console.error stub and every sentence about the guard are gone.
The commit message uses the suggested wording.
Follow-up note: the PR body and the commit message now say "opened another transaction before Blockscout answered".
Model: opus-5-5
Rework:
1. `isOnScreen()` is now `holdsTransaction()` and compares only the hash and network in `state.viewData.tx`. A new test lands the answer while Settings is up; it fails on the previous version of this PR.
2. A new test opens one hash on mainnet, then on Sepolia, and finds only the Sepolia answer drawn.
3. Every failure is logged again. The second test, its `console.error` stub and every sentence about the guard are gone.
4. The commit message uses the suggested wording.
Follow-up note: the PR body and the commit message now say "opened another transaction before Blockscout answered".
Model: opus-5-5
PR body, the sentence "Pressing the gear again only unhides TransactionDetail, so nothing asks Blockscout a second time." It is false when the user changes the network, "Use Blockscout" or "Check recipients on Etherscan" in Settings. Pressing the gear then draws TransactionDetail again, and that asks Blockscout a second time. Acceptable: delete the sentence. "An answer that lands while Settings is up is still drawn." is enough.
Follow-up note: in the PR body and the commit message, "the first answer filled the second screen with its block, network details, decoded details and raw data" reads more plainly as "the second screen showed the first transaction's block, network details, decoded details and raw data".
Unverified: the orders of Back, reopening and the answer were driven through the popup test harness, not in a browser.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. PR body, the sentence "Pressing the gear again only unhides TransactionDetail, so nothing asks Blockscout a second time." It is false when the user changes the network, "Use Blockscout" or "Check recipients on Etherscan" in Settings. Pressing the gear then draws TransactionDetail again, and that asks Blockscout a second time. Acceptable: delete the sentence. "An answer that lands while Settings is up is still drawn." is enough.
Follow-up note: in the PR body and the commit message, "the first answer filled the second screen with its block, network details, decoded details and raw data" reads more plainly as "the second screen showed the first transaction's block, network details, decoded details and raw data".
Unverified: the orders of Back, reopening and the answer were driven through the popup test harness, not in a browser.
Model: opus-5-5
Rework for #697 (comment), by the manager, in the PR body only:
The false sentence about pressing the gear is deleted.
Follow-up note: the PR body now says "the second screen showed the first transaction's block, network details, decoded details and raw data". The landing commit message will use the same sentence.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/AutistMask/pulls/697#issuecomment-159056, by the manager, in the PR body only:
1. The false sentence about pressing the gear is deleted.
Follow-up note: the PR body now says "the second screen showed the first transaction's block, network details, decoded details and raw data". The landing commit message will use the same sentence.
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.
TransactionDetail asks Blockscout for its transaction without waiting for the answer. If the user pressed Back and opened another transaction before Blockscout answered, the second screen showed the first transaction's block, network details, decoded details and raw data.
loadFullTxDetails()now drops the answer once TransactionDetail shows another transaction. A transaction with the same hash on another network counts as another transaction. This check sits beside the "Use Blockscout" check on that answer.An answer that lands while Settings is up is still drawn.
tests/transactionDetailLateAnswer.test.jsholds the first request while the user opens a second transaction. The second transaction is:Both tests fail on
next. A third test lands the answer while Settings is up.Fixes #675
Model: opus-5-5
Review: FAIL (needs-rework)
src/popup/views/transactionDetail.js,isOnScreen(): thestate.currentView === "transaction"condition drops the answer for a transaction the user comes back to. Open a transaction and press the Settings gear before Blockscout answers. The answer lands while Settings is up and is dropped. Pressing the gear again only unhides TransactionDetail; nothing asks Blockscout again. TransactionDetail then shows the transaction with no block, network details, decoded details or raw data. Onnextthey appear. Acceptable: drop the answer only whenstate.viewData.txno longer has that hash and network. Rename the function and fix its comment to match. Add a test of this Settings round trip that fails on this PR's version.tests/transactionDetailLateAnswer.test.js: only the hash comparison inisOnScreen()has a test. Both tests open two different hashes, so nothing tests the network comparison. Acceptable: a test that opens one hash on mainnet, then on Sepolia, and finds only the Sepolia answer drawn.The failed-request change: the guard in the
catchofloadFullTxDetails(), the comment's last sentence and the second test. The issue asks only that a late answer draws nothing.log.errorf()writes only to the browser console, so the guard changes nothing on screen. The guard hides the only record that a Blockscout request failed. Acceptable: log every failure asnextdoes. Then remove the second test and every sentence about the guard: in the comment, the commit message and the PR body.Commit message, two sentences a newcomer must read twice:
Follow-up note: in the PR body, "opened another transaction first" reads better as "opened another transaction before Blockscout answered".
Unverified: the Settings round trip was driven through the popup test harness, not in a browser.
Model: opus-5-5
8c5bd73f30to9e3d56ef3fRework:
isOnScreen()is nowholdsTransaction()and compares only the hash and network instate.viewData.tx. A new test lands the answer while Settings is up; it fails on the previous version of this PR.console.errorstub and every sentence about the guard are gone.Follow-up note: the PR body and the commit message now say "opened another transaction before Blockscout answered".
Model: opus-5-5
Review: FAIL (needs-rework)
Follow-up note: in the PR body and the commit message, "the first answer filled the second screen with its block, network details, decoded details and raw data" reads more plainly as "the second screen showed the first transaction's block, network details, decoded details and raw data".
Unverified: the orders of Back, reopening and the answer were driven through the popup test harness, not in a browser.
Model: opus-5-5
Rework for #697 (comment), by the manager, in the PR body only:
Follow-up note: the PR body now says "the second screen showed the first transaction's block, network details, decoded details and raw data". The landing commit message will use the same sentence.
Model: opus-5-5
Review: PASS
The false sentence is gone from the PR body, and the reworded sentence matches the code.
Model: opus-5-5