why are we changing the approval flow? browsers frequently close the popup when clicked away, such as to access a password manager to get the signing passphrase. why do we support cancelling with anything other than the cancel button?
What the code does now
A transaction or signing approval opens in its own window (windows.create() in src/background/index.js). When that window closes for any reason, the windows.onRemoved listener rejects the request with EIP-1193 code 4001, as if the user had pressed Cancel. A user who leaves the window to fetch the passphrase from a password manager can lose the request this way.
What it must do
A pending approval is cancelled only by its Cancel button. Closing or losing its window leaves it pending, and the user can bring it back and answer it.
Definition of done
Closing a transaction or signing approval window leaves the request pending; the site gets no answer.
Opening the wallet again shows the pending request, and the user can approve or cancel it there.
Only the Cancel button rejects a pending request with code 4001.
The Chrome suite covers both paths: close the window, reopen, approve; and close, reopen, cancel.
The README and the user guide describe this behaviour.
RULES.md already says approvals persist across a popup close and reopen, so it needs no change.
Model: opus-5-5
sneak, on https://git.eeqj.de/sneak/AutistMask/issues/211#issuecomment-154472:
> why are we changing the approval flow? browsers frequently close the popup when clicked away, such as to access a password manager to get the signing passphrase. why do we support cancelling with anything other than the cancel button?
## What the code does now
A transaction or signing approval opens in its own window (`windows.create()` in `src/background/index.js`). When that window closes for any reason, the `windows.onRemoved` listener rejects the request with EIP-1193 code 4001, as if the user had pressed Cancel. A user who leaves the window to fetch the passphrase from a password manager can lose the request this way.
## What it must do
A pending approval is cancelled only by its Cancel button. Closing or losing its window leaves it pending, and the user can bring it back and answer it.
## Definition of done
- [ ] Closing a transaction or signing approval window leaves the request pending; the site gets no answer.
- [ ] Opening the wallet again shows the pending request, and the user can approve or cancel it there.
- [ ] Only the Cancel button rejects a pending request with code 4001.
- [ ] The Chrome suite covers both paths: close the window, reopen, approve; and close, reopen, cancel.
- [ ] The README and the user guide describe this behaviour.
- [ ] `RULES.md` already says approvals persist across a popup close and reopen, so it needs no change.
Model: opus-5-5
clawbot
self-assigned this 2026-10-24 08:22:11 +02:00
src/background/index.js: the windows.onRemoved listener no longer settles a transaction or signing approval. The approval stays in pendingApprovals, the site gets no answer, and the worker keeps running as it does for any pending approval.
Reopening: once such an approval's window is gone, pressing the toolbar icon opens the popup onto it (?approval= and the approval's id, as a site-connection approval already does), with the same Approve / Cancel and password field. With more than one pending, the oldest comes first.
Only Cancel answers the site with 4001. Kept as they are, each a choice the user makes inside the wallet or a wallet failure, not a closed window: an address switch made in the wallet still ends approvals pinned to the old address, and a window that could not be opened still answers -32603.
The stale port-disconnect comment becomes true again; the comments over onRemoved and the approval port say what the code now does.
Chrome suite: close the window, reopen from the toolbar, approve; close, reopen, cancel; the site gets no answer while the window is closed.
README.md and docs/README.md describe it. RULES.md already says so and is not touched.
Model: opus-5-5
Plan: one PR to `next`.
- `src/background/index.js`: the `windows.onRemoved` listener no longer settles a transaction or signing approval. The approval stays in `pendingApprovals`, the site gets no answer, and the worker keeps running as it does for any pending approval.
- Reopening: once such an approval's window is gone, pressing the toolbar icon opens the popup onto it (`?approval=` and the approval's id, as a site-connection approval already does), with the same Approve / Cancel and password field. With more than one pending, the oldest comes first.
- Only Cancel answers the site with 4001. Kept as they are, each a choice the user makes inside the wallet or a wallet failure, not a closed window: an address switch made in the wallet still ends approvals pinned to the old address, and a window that could not be opened still answers -32603.
- The stale port-disconnect comment becomes true again; the comments over `onRemoved` and the approval port say what the code now does.
- Chrome suite: close the window, reopen from the toolbar, approve; close, reopen, cancel; the site gets no answer while the window is closed.
- `README.md` and `docs/README.md` describe it. `RULES.md` already says so and is not touched.
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.
sneak, on #211 (comment):
What the code does now
A transaction or signing approval opens in its own window (
windows.create()insrc/background/index.js). When that window closes for any reason, thewindows.onRemovedlistener rejects the request with EIP-1193 code 4001, as if the user had pressed Cancel. A user who leaves the window to fetch the passphrase from a password manager can lose the request this way.What it must do
A pending approval is cancelled only by its Cancel button. Closing or losing its window leaves it pending, and the user can bring it back and answer it.
Definition of done
RULES.mdalready says approvals persist across a popup close and reopen, so it needs no change.Model: opus-5-5
Plan: one PR to
next.src/background/index.js: thewindows.onRemovedlistener no longer settles a transaction or signing approval. The approval stays inpendingApprovals, the site gets no answer, and the worker keeps running as it does for any pending approval.?approval=and the approval's id, as a site-connection approval already does), with the same Approve / Cancel and password field. With more than one pending, the oldest comes first.onRemovedand the approval port say what the code now does.README.mdanddocs/README.mddescribe it.RULES.mdalready says so and is not touched.Model: opus-5-5