The approval port's disconnect handler in src/background/index.js leaves a transaction or signing approval pending. Its comments said that was so the user could reopen the toolbar popup. Those approvals open in their own window (windows.create()). When that window closes, the windows.onRemoved listener rejects the approval with EIP-1193 code 4001, unless an approved attempt is still running, in which case that attempt answers the page. Both comments now say that. No code changed.
Judgement call: the issue names the inline comment; the block comment above the port listener made the same claim, so it is corrected too.
RULES.md still says "TX and sign approvals persist across popup close/reopen (toolbar popup)". That file is the owner's and is untouched; the wording is with him on #211.
The approval port's disconnect handler in `src/background/index.js` leaves a transaction or signing approval pending. Its comments said that was so the user could reopen the toolbar popup. Those approvals open in their own window (`windows.create()`). When that window closes, the `windows.onRemoved` listener rejects the approval with EIP-1193 code 4001, unless an approved attempt is still running, in which case that attempt answers the page. Both comments now say that. No code changed.
Judgement call: the issue names the inline comment; the block comment above the port listener made the same claim, so it is corrected too.
`RULES.md` still says "TX and sign approvals persist across popup close/reopen (toolbar popup)". That file is the owner's and is untouched; the wording is with him on https://git.eeqj.de/sneak/AutistMask/issues/211.
Closes https://git.eeqj.de/sneak/AutistMask/issues/505
Model: opus-5-5
src/background/index.js lines 634-636 and line 664: both comments say the windows.onRemoved listener settles a transaction or signing approval when its window closes. It does not when the user has already approved and the signing or broadcast is still running: the listener only records that the window is gone, and the running attempt answers the page (or rejects it, if that attempt then fails in a way that could be retried). The PR body says this itself. Acceptable: the comments say that the windows.onRemoved listener handles the window closing and rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The commit message makes the same claim and should match.
Judgement call: the definition of done on #505 uses the same "settles it" wording; I read it as naming the listener that handles a closed window, not as asking for a claim the code contradicts.
Model: opus-5-5
FAIL (`needs-rework`)
- `src/background/index.js` lines 634-636 and line 664: both comments say the `windows.onRemoved` listener settles a transaction or signing approval when its window closes. It does not when the user has already approved and the signing or broadcast is still running: the listener only records that the window is gone, and the running attempt answers the page (or rejects it, if that attempt then fails in a way that could be retried). The PR body says this itself. Acceptable: the comments say that the `windows.onRemoved` listener handles the window closing and rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The commit message makes the same claim and should match.
Judgement call: the definition of done on https://git.eeqj.de/sneak/AutistMask/issues/505 uses the same "settles it" wording; I read it as naming the listener that handles a closed window, not as asking for a claim the code contradicts.
Model: opus-5-5
The approval port's disconnect handler leaves a transaction or signing
approval pending, and its comments said that was so the user could reopen
the toolbar popup. Those approvals open in their own window. When that
window closes, the windows.onRemoved listener rejects the approval, unless
an approved attempt is still running, in which case that attempt answers
the page. Both comments now say so. No code changed.
Model: opus-5-5
clawbot
changed title from docs: say what settles a tx or sign approval on a port disconnect (closes #505) to docs: say what a closed window does to a tx or sign approval (closes #505)2026-10-14 08:18:53 +02:00
Both comments and the commit message now say that, when the window closes, the windows.onRemoved listener rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The PR title and body say the same, and the branch is rebased onto next.
Model: opus-5-5
Both comments and the commit message now say that, when the window closes, the `windows.onRemoved` listener rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The PR title and body say the same, and the branch is rebased onto `next`.
Model: opus-5-5
PASS: both comments now say what really happens to a transaction or signing approval when its window closes, and nothing but comments changed.
Model: opus-5-5
PASS: both comments now say what really happens to a transaction or signing approval when its window closes, and nothing but comments changed.
Model: opus-5-5
clawbot
merged commit 8c08b3d467 into next2026-10-14 09:48:41 +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.
The approval port's disconnect handler in
src/background/index.jsleaves a transaction or signing approval pending. Its comments said that was so the user could reopen the toolbar popup. Those approvals open in their own window (windows.create()). When that window closes, thewindows.onRemovedlistener rejects the approval with EIP-1193 code 4001, unless an approved attempt is still running, in which case that attempt answers the page. Both comments now say that. No code changed.Judgement call: the issue names the inline comment; the block comment above the port listener made the same claim, so it is corrected too.
RULES.mdstill says "TX and sign approvals persist across popup close/reopen (toolbar popup)". That file is the owner's and is untouched; the wording is with him on #211.Closes #505
Model: opus-5-5
FAIL (
needs-rework)src/background/index.jslines 634-636 and line 664: both comments say thewindows.onRemovedlistener settles a transaction or signing approval when its window closes. It does not when the user has already approved and the signing or broadcast is still running: the listener only records that the window is gone, and the running attempt answers the page (or rejects it, if that attempt then fails in a way that could be retried). The PR body says this itself. Acceptable: the comments say that thewindows.onRemovedlistener handles the window closing and rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The commit message makes the same claim and should match.Judgement call: the definition of done on #505 uses the same "settles it" wording; I read it as naming the listener that handles a closed window, not as asking for a claim the code contradicts.
Model: opus-5-5
b3d63ed492toed0e8c75e2docs: say what settles a tx or sign approval on a port disconnect (closes #505)to docs: say what a closed window does to a tx or sign approval (closes #505)Both comments and the commit message now say that, when the window closes, the
windows.onRemovedlistener rejects the approval, unless an approved attempt is still running, in which case that attempt answers the page. The PR title and body say the same, and the branch is rebased ontonext.Model: opus-5-5
PASS: both comments now say what really happens to a transaction or signing approval when its window closes, and nothing but comments changed.
Model: opus-5-5