WaitTx asked the active network's node for the receipt. So when the popup reopened onto it after a network switch, it never found the transaction and reported a timeout. It now asks the node of the network the transaction's chain id names, through reviewedNetworkProvider(). That function moved unchanged from ConfirmTx into src/popup/views/helpers.js, so both screens call the same one. WaitTx's To and hash links, and every link on TransactionDetail (hash, From, To, token contract, block, decoded addresses), now open that network's explorer.
What a reader may trip over:
The chain id now picks a node and an explorer, so an unknown one would throw on restore. restoreWait() refuses a stored wait whose chain id names no network. The stored-transaction check in viewRouter.js likewise refuses a transaction whose chain id names none, as the ConfirmTx check already does. Both callers of WaitTx always set a known chain id.
Test fixtures that showed WaitTx without a chain id now carry one, as every real transaction does. tests/tokenTransferDetail.test.js passed 1 where fetchRecentTransactions() takes the chain id; it now passes mainnet's.
Left as they were, outside this issue:
SuccessTx and ErrorTx, which follow WaitTx, still link to the active network's explorer.
TransactionDetail still reads its block, fee and calldata from the active network's Blockscout API. With the other network active, those sections stay empty.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/584.
WaitTx asked the active network's node for the receipt. So when the popup reopened onto it after a network switch, it never found the transaction and reported a timeout. It now asks the node of the network the transaction's chain id names, through `reviewedNetworkProvider()`. That function moved unchanged from ConfirmTx into `src/popup/views/helpers.js`, so both screens call the same one. WaitTx's To and hash links, and every link on TransactionDetail (hash, From, To, token contract, block, decoded addresses), now open that network's explorer.
What a reader may trip over:
- The chain id now picks a node and an explorer, so an unknown one would throw on restore. `restoreWait()` refuses a stored wait whose chain id names no network. The stored-transaction check in `viewRouter.js` likewise refuses a transaction whose chain id names none, as the ConfirmTx check already does. Both callers of WaitTx always set a known chain id.
- Test fixtures that showed WaitTx without a chain id now carry one, as every real transaction does. `tests/tokenTransferDetail.test.js` passed `1` where `fetchRecentTransactions()` takes the chain id; it now passes mainnet's.
Left as they were, outside this issue:
- SuccessTx and ErrorTx, which follow WaitTx, still link to the active network's explorer.
- TransactionDetail still reads its block, fee and calldata from the active network's Blockscout API. With the other network active, those sections stay empty.
Model: opus-5-5
WaitTx asked the active network's node for the receipt, so after a network
switch a transaction sent on the other network was never found and was
reported as timed out. It now asks the node of the network its chain id
names, through reviewedNetworkProvider(), moved from ConfirmTx into the
shared view helpers so both screens use one function. WaitTx and
TransactionDetail build their explorer links for that network too. A stored
wait or transaction whose chain id names no network is refused on restore,
as a stored ConfirmTx transaction already is.
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 #584.
WaitTx asked the active network's node for the receipt. So when the popup reopened onto it after a network switch, it never found the transaction and reported a timeout. It now asks the node of the network the transaction's chain id names, through
reviewedNetworkProvider(). That function moved unchanged from ConfirmTx intosrc/popup/views/helpers.js, so both screens call the same one. WaitTx's To and hash links, and every link on TransactionDetail (hash, From, To, token contract, block, decoded addresses), now open that network's explorer.What a reader may trip over:
restoreWait()refuses a stored wait whose chain id names no network. The stored-transaction check inviewRouter.jslikewise refuses a transaction whose chain id names none, as the ConfirmTx check already does. Both callers of WaitTx always set a known chain id.tests/tokenTransferDetail.test.jspassed1wherefetchRecentTransactions()takes the chain id; it now passes mainnet's.Left as they were, outside this issue:
Model: opus-5-5
Review: PASS
Model: opus-5-5