The confirm-tx view was not in RESTORABLE_VIEWS, so closing and reopening the popup during transaction confirmation would lose the view and return to main.
Fix:
Add confirm-tx to RESTORABLE_VIEWS
Save pendingTx data in state.viewData before showing the confirm view
Add restore() function that re-renders from persisted viewData
Add restore case in restoreView() switch
On popup reopen, the full confirmation screen (amounts, addresses, warnings, gas estimate) is re-rendered from persisted state.
docker build . passes.
The `confirm-tx` view was not in `RESTORABLE_VIEWS`, so closing and reopening the popup during transaction confirmation would lose the view and return to `main`.
Fix:
- Add `confirm-tx` to `RESTORABLE_VIEWS`
- Save `pendingTx` data in `state.viewData` before showing the confirm view
- Add `restore()` function that re-renders from persisted `viewData`
- Add restore case in `restoreView()` switch
On popup reopen, the full confirmation screen (amounts, addresses, warnings, gas estimate) is re-rendered from persisted state.
`docker build .` passes.
Add confirm-tx to RESTORABLE_VIEWS and save pendingTx in
state.viewData so the confirmation screen survives the popup
lifecycle. On restore, re-render the full confirmation view
including gas estimate.
@sneak good question — the gas is re-estimated on popup reopen. restore() calls show(pendingTx), which sets the fee to "Estimating..." and calls estimateGas(txInfo) asynchronously. Only the transaction parameters (to, amount, token) are persisted; gas is always fresh.
The PR description saying "re-rendered from persisted state" is slightly misleading — only the tx params are persisted, gas is recalculated live.
Changes summary
confirm-tx added to RESTORABLE_VIEWS
pendingTx saved to state.viewData in show()
New restore() re-calls show() (which re-estimates gas)
Fallback to main view if viewData is missing
Clean, minimal, correct. Ready to merge.
## Review: ✅ merge-ready
**Code review passed.** Build passes.
### Re: gas re-calculation concern
@sneak good question — the gas **is** re-estimated on popup reopen. `restore()` calls `show(pendingTx)`, which sets the fee to "Estimating..." and calls `estimateGas(txInfo)` asynchronously. Only the transaction parameters (to, amount, token) are persisted; gas is always fresh.
The PR description saying "re-rendered from persisted state" is slightly misleading — only the tx params are persisted, gas is recalculated live.
### Changes summary
- `confirm-tx` added to `RESTORABLE_VIEWS`
- `pendingTx` saved to `state.viewData` in `show()`
- New `restore()` re-calls `show()` (which re-estimates gas)
- Fallback to main view if viewData is missing
Clean, minimal, correct. Ready to merge.
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.
The
confirm-txview was not inRESTORABLE_VIEWS, so closing and reopening the popup during transaction confirmation would lose the view and return tomain.Fix:
confirm-txtoRESTORABLE_VIEWSpendingTxdata instate.viewDatabefore showing the confirm viewrestore()function that re-renders from persistedviewDatarestoreView()switchOn popup reopen, the full confirmation screen (amounts, addresses, warnings, gas estimate) is re-rendered from persisted state.
docker build .passes.shouldnt gas estimate be re-calculated, given that it might be an hour later?
Review: ✅ merge-ready
Code review passed. Build passes.
Re: gas re-calculation concern
@sneak good question — the gas is re-estimated on popup reopen.
restore()callsshow(pendingTx), which sets the fee to "Estimating..." and callsestimateGas(txInfo)asynchronously. Only the transaction parameters (to, amount, token) are persisted; gas is always fresh.The PR description saying "re-rendered from persisted state" is slightly misleading — only the tx params are persisted, gas is recalculated live.
Changes summary
confirm-txadded toRESTORABLE_VIEWSpendingTxsaved tostate.viewDatainshow()restore()re-callsshow()(which re-estimates gas)Clean, minimal, correct. Ready to merge.
9f85758ef6to78f961f416