Closing a transaction or signature approval window no longer rejects the request. The browser can close that window when the user clicks away, for example to copy the password from a password manager.
windows.onRemoved marks a closed tx or sign approval and leaves it in pendingApprovals, so the site gets no answer.
updateToolbarPopup() points the toolbar popup at the oldest pending approval whose window closed, or back at the wallet. An approval that an attempt holds is skipped until the attempt ends. The worker also calls it at startup, because a restarted worker holds no approvals.
releaseApproval() no longer rejects an approval whose window closed during a failed attempt. The toolbar popup opens it for a retry.
Reject closes its window only after the background answers. A rejection sent as the window closed got lost in the Chrome suite. A rejection the background refuses leaves the window open with the background's message.
Worth knowing: the transaction slot stays held until the user answers, so another eth_sendTransaction gets -32002 meanwhile.
Disclosures:
Kept: an address switch in the wallet still rejects pending approvals with 4001, and a window that could not be opened still answers -32603.
RULES.md is untouched; it already says approvals persist across a popup close.
Judgement call: the Chrome suite signs a reopened signature request and rejects a reopened transaction. Its stub node answers every nonce request with 0, so a run can approve one dApp transaction only. Unit tests approve a reopened transaction.
Model: opus-5-5
Closing a transaction or signature approval window no longer rejects the request. The browser can close that window when the user clicks away, for example to copy the password from a password manager.
- `windows.onRemoved` marks a closed `tx` or `sign` approval and leaves it in `pendingApprovals`, so the site gets no answer.
- `updateToolbarPopup()` points the toolbar popup at the oldest pending approval whose window closed, or back at the wallet. An approval that an attempt holds is skipped until the attempt ends. The worker also calls it at startup, because a restarted worker holds no approvals.
- `releaseApproval()` no longer rejects an approval whose window closed during a failed attempt. The toolbar popup opens it for a retry.
- Reject closes its window only after the background answers. A rejection sent as the window closed got lost in the Chrome suite. A rejection the background refuses leaves the window open with the background's message.
Worth knowing: the transaction slot stays held until the user answers, so another `eth_sendTransaction` gets `-32002` meanwhile.
Disclosures:
- Kept: an address switch in the wallet still rejects pending approvals with 4001, and a window that could not be opened still answers `-32603`.
- `RULES.md` is untouched; it already says approvals persist across a popup close.
- Judgement call: the Chrome suite signs a reopened signature request and rejects a reopened transaction. Its stub node answers every nonce request with 0, so a run can approve one dApp transaction only. Unit tests approve a reopened transaction.
Model: opus-5-5
README.md line 484 (limits of the Chrome suite): "So that prompt, and an approval reopened after its window closed, are driven at the URL … whether a real toolbar click shows it is not observable here." runs to 43 words, and "it" can mean either the prompt or the approval. Acceptable: "So that prompt, and an approval reopened after its window closed, are opened in a tab at the URL the extension puts on the action. Whether a real toolbar click shows that page is not observable here."
README.md line 606 (Firefox suite): the sentence this PR changes, "It covers popup load, … driven through the real content script, background page and approval windows.", runs to about 70 words and chains the covered flows with commas. Acceptable: a short lead sentence, then a bulleted list of what the suite covers, with the closed approval window as its own bullet.
README.md line 2493 (TxApproval): "With several closed requests waiting" reads as requests that are finished yet still waiting. Acceptable: "When several requests wait with their windows closed, the toolbar button opens the oldest first."
src/background/index.js line 1481: "A site-connection or network-switch approval whose window closes is rejected, unless its popup connected its port." Read alone, it says a connected port spares the approval, yet the port's disconnect rejects it; the next sentences have to undo it. Acceptable: "This listener rejects a site-connection or network-switch approval whose window closes before its popup connected its port. Once the port is connected, the approval is left to the port."
src/background/index.js line 391: resetPopupUrl() now also points the toolbar popup at a closed approval, and its comment opens with "Set the toolbar popup back to the wallet." The window-close listener calls it right after marking an approval closed, to do the opposite of a reset. Acceptable: a name that says what it does, such as updateToolbarPopup(), and a comment that opens on the rule: "Point the toolbar popup at the oldest pending approval whose window closed, or at the wallet when there is none."
src/background/index.js line 435: the abandonedResult() comment lists its cases as a closed site-connection or network-switch window, or a window that could not be opened. It leaves out the address switch, which broadcastAccountsChanged() also sends through it. For a transaction or signature approval, that is now one of the only two cases. Acceptable: name the address switch too, in a short sentence.
tests/approvalWindow.test.js line 182: "the site would then wait for good" is false. A lost rejection leaves the request pending, and the toolbar popup opens it again. Acceptable: "and the request would stay pending although the user rejected it."
Follow-up note: the PR body runs to about 270 words, and "the old close-rejects behaviour" is a made-up term; "the old rule that a closed window rejects the request" says it plainly.
Judgement call: an address switch still answers 4001. I read that as within the definition of done, because the plan at #673 (comment) keeps it.
Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab instead), and the worker-restart case the PR body discloses.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. `README.md` line 484 (limits of the Chrome suite): "So that prompt, and an approval reopened after its window closed, are driven at the URL … whether a real toolbar click shows it is not observable here." runs to 43 words, and "it" can mean either the prompt or the approval. Acceptable: "So that prompt, and an approval reopened after its window closed, are opened in a tab at the URL the extension puts on the action. Whether a real toolbar click shows that page is not observable here."
2. `README.md` line 606 (Firefox suite): the sentence this PR changes, "It covers popup load, … driven through the real content script, background page and approval windows.", runs to about 70 words and chains the covered flows with commas. Acceptable: a short lead sentence, then a bulleted list of what the suite covers, with the closed approval window as its own bullet.
3. `README.md` line 2493 (TxApproval): "With several closed requests waiting" reads as requests that are finished yet still waiting. Acceptable: "When several requests wait with their windows closed, the toolbar button opens the oldest first."
4. `src/background/index.js` line 1481: "A site-connection or network-switch approval whose window closes is rejected, unless its popup connected its port." Read alone, it says a connected port spares the approval, yet the port's disconnect rejects it; the next sentences have to undo it. Acceptable: "This listener rejects a site-connection or network-switch approval whose window closes before its popup connected its port. Once the port is connected, the approval is left to the port."
5. `src/background/index.js` line 391: `resetPopupUrl()` now also points the toolbar popup at a closed approval, and its comment opens with "Set the toolbar popup back to the wallet." The window-close listener calls it right after marking an approval closed, to do the opposite of a reset. Acceptable: a name that says what it does, such as `updateToolbarPopup()`, and a comment that opens on the rule: "Point the toolbar popup at the oldest pending approval whose window closed, or at the wallet when there is none."
6. `src/background/index.js` line 435: the `abandonedResult()` comment lists its cases as a closed site-connection or network-switch window, or a window that could not be opened. It leaves out the address switch, which `broadcastAccountsChanged()` also sends through it. For a transaction or signature approval, that is now one of the only two cases. Acceptable: name the address switch too, in a short sentence.
7. `tests/approvalWindow.test.js` line 182: "the site would then wait for good" is false. A lost rejection leaves the request pending, and the toolbar popup opens it again. Acceptable: "and the request would stay pending although the user rejected it."
Follow-up note: the PR body runs to about 270 words, and "the old close-rejects behaviour" is a made-up term; "the old rule that a closed window rejects the request" says it plainly.
Judgement call: an address switch still answers 4001. I read that as within the definition of done, because the plan at https://git.eeqj.de/sneak/AutistMask/issues/673#issuecomment-154739 keeps it.
Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab instead), and the worker-restart case the PR body discloses.
Model: opus-5-5
README.md, limits of the Chrome suite: took the suggested wording.
README.md, Firefox suite: a short lead sentence, then a bulleted list; the closed approval window is its own bullet.
README.md, TxApproval: took the suggested wording.
Window-close listener comment: now opens with the two suggested sentences.
resetPopupUrl() is now updateToolbarPopup() at its definition, every call site and the comments; its comment opens on the rule.
abandonedResult() comment now names the address switch, in its own sentence.
tests/approvalWindow.test.js: took the suggested wording.
Startup: the background calls updateToolbarPopup() once when the worker starts. A new unit test loads the background with the toolbar popup pointing at an approval and finds it pointing at the wallet. The "Unverified" line is gone from the PR body.
Follow-up note: the PR body is shorter and uses "the old rule that a closed window rejects the request".
The new background tests stub the worker's keep-running timer, so they leave no timer running.
Judgement call: two older tests this PR edits, in other groups, still end with an approval pending, as their neighbours do. #585 covers that.
Model: opus-5-5
Rework pushed.
1. `README.md`, limits of the Chrome suite: took the suggested wording.
2. `README.md`, Firefox suite: a short lead sentence, then a bulleted list; the closed approval window is its own bullet.
3. `README.md`, TxApproval: took the suggested wording.
4. Window-close listener comment: now opens with the two suggested sentences.
5. `resetPopupUrl()` is now `updateToolbarPopup()` at its definition, every call site and the comments; its comment opens on the rule.
6. `abandonedResult()` comment now names the address switch, in its own sentence.
7. `tests/approvalWindow.test.js`: took the suggested wording.
- Startup: the background calls `updateToolbarPopup()` once when the worker starts. A new unit test loads the background with the toolbar popup pointing at an approval and finds it pointing at the wallet. The "Unverified" line is gone from the PR body.
- Follow-up note: the PR body is shorter and uses "the old rule that a closed window rejects the request".
- The new background tests stub the worker's keep-running timer, so they leave no timer running.
- Judgement call: two older tests this PR edits, in other groups, still end with an approval pending, as their neighbours do. https://git.eeqj.de/sneak/AutistMask/issues/585 covers that.
Model: opus-5-5
src/background/index.js, the windows.onRemoved listener and updateToolbarPopup(): when a window closes while its approved transaction is still being verified or broadcast, the toolbar popup is pointed at that approval at once. Opened from the toolbar, it shows as a fresh request, with an empty password field, Confirm and Reject. Reject there is refused by the background ("This transaction is already being sent."), but the popup closes anyway. The user believes the request was rejected while the transaction goes out. The comments in this file call closing a window during a slow broadcast an ordinary event. Acceptable: updateToolbarPopup() skips an approval that an attempt holds, and runs again when an attempt claims or releases one. A unit test closes the window during an attempt and finds the toolbar popup opening the wallet until the attempt ends.
Judgement call: an address switch still answers a waiting transaction or signature request with 4001, although the definition of done says only Cancel does. I read it as kept by the plan at #673 (comment); only the owner can change that.
Unverified: a real toolbar click on a reopened approval. Both browser suites open the toolbar's URL in a tab instead.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. `src/background/index.js`, the `windows.onRemoved` listener and `updateToolbarPopup()`: when a window closes while its approved transaction is still being verified or broadcast, the toolbar popup is pointed at that approval at once. Opened from the toolbar, it shows as a fresh request, with an empty password field, Confirm and Reject. Reject there is refused by the background ("This transaction is already being sent."), but the popup closes anyway. The user believes the request was rejected while the transaction goes out. The comments in this file call closing a window during a slow broadcast an ordinary event. Acceptable: `updateToolbarPopup()` skips an approval that an attempt holds, and runs again when an attempt claims or releases one. A unit test closes the window during an attempt and finds the toolbar popup opening the wallet until the attempt ends.
Judgement call: an address switch still answers a waiting transaction or signature request with 4001, although the definition of done says only Cancel does. I read it as kept by the plan at https://git.eeqj.de/sneak/AutistMask/issues/673#issuecomment-154739; only the owner can change that.
Unverified: a real toolbar click on a reopened approval. Both browser suites open the toolbar's URL in a tab instead.
Model: opus-5-5
updateToolbarPopup() skips an approval that an attempt holds, and claimApproval() and releaseApproval() call it. The toolbar popup opens the wallet until the attempt ends.
A Reject the background refuses keeps the approval screen open, with the background's message on its error line. The TxApproval and SignApproval transitions in README.md say so.
Model: opus-5-5
Rework pushed.
1. `updateToolbarPopup()` skips an approval that an attempt holds, and `claimApproval()` and `releaseApproval()` call it. The toolbar popup opens the wallet until the attempt ends.
2. A Reject the background refuses keeps the approval screen open, with the background's message on its error line. The TxApproval and SignApproval transitions in `README.md` say so.
Model: opus-5-5
src/background/index.js, the comment over TX_APPROVAL_PENDING_MESSAGE (lines 163–166): "the other request is either being prepared or on screen" is now false. A transaction approval whose window closed keeps the slot while it is neither. Acceptable: "…so the other request is being prepared, is on screen, or waits with its window closed."
README.md lines 515–517 (the Chrome suite's dApp round trips): in "The suite then answers it from the page the toolbar button opens.", "it" can be read as the dApp page that the sentence before leaves "without an answer", and "the page" names two different pages in two sentences. Acceptable: "Closing a transaction or signature approval window is required to leave the dApp's request unanswered. The suite then opens that approval at the URL the toolbar button holds, and answers it there."
Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab), and a worker restart while an approval waits, which I read but did not run.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. `src/background/index.js`, the comment over `TX_APPROVAL_PENDING_MESSAGE` (lines 163–166): "the other request is either being prepared or on screen" is now false. A transaction approval whose window closed keeps the slot while it is neither. Acceptable: "…so the other request is being prepared, is on screen, or waits with its window closed."
2. `README.md` lines 515–517 (the Chrome suite's dApp round trips): in "The suite then answers it from the page the toolbar button opens.", "it" can be read as the dApp page that the sentence before leaves "without an answer", and "the page" names two different pages in two sentences. Acceptable: "Closing a transaction or signature approval window is required to leave the dApp's request unanswered. The suite then opens that approval at the URL the toolbar button holds, and answers it there."
Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab), and a worker restart while an approval waits, which I read but did not run.
Model: opus-5-5
The browser can close the approval window when the user clicks away from it,
for example to copy the password from a password manager. Closing it used to
reject the request with 4001. Now the request stays pending and the site gets
no answer. Until it is answered, the toolbar popup opens the oldest such
approval. The toolbar popup skips an approval while its transaction is being
sent or its signature checked. A worker that starts holds no approvals, so it
points the toolbar popup back at the wallet.
Reject now closes its window only after the background has the rejection. A
rejection the background refuses leaves the window open with the background's
message.
Site-connection and network-switch windows still reject the request when
closed.
Model: opus-5-5
The comment over TX_APPROVAL_PENDING_MESSAGE now uses the suggested wording.
The README's two sentences on the Chrome suite's dApp round trips now use the suggested wording.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/AutistMask/pulls/676#issuecomment-157101:
1. The comment over `TX_APPROVAL_PENDING_MESSAGE` now uses the suggested wording.
2. The README's two sentences on the Chrome suite's dApp round trips now use the suggested wording.
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.
Closing a transaction or signature approval window no longer rejects the request. The browser can close that window when the user clicks away, for example to copy the password from a password manager.
windows.onRemovedmarks a closedtxorsignapproval and leaves it inpendingApprovals, so the site gets no answer.updateToolbarPopup()points the toolbar popup at the oldest pending approval whose window closed, or back at the wallet. An approval that an attempt holds is skipped until the attempt ends. The worker also calls it at startup, because a restarted worker holds no approvals.releaseApproval()no longer rejects an approval whose window closed during a failed attempt. The toolbar popup opens it for a retry.Worth knowing: the transaction slot stays held until the user answers, so another
eth_sendTransactiongets-32002meanwhile.Disclosures:
-32603.RULES.mdis untouched; it already says approvals persist across a popup close.Model: opus-5-5
Review: FAIL (needs-rework)
README.mdline 484 (limits of the Chrome suite): "So that prompt, and an approval reopened after its window closed, are driven at the URL … whether a real toolbar click shows it is not observable here." runs to 43 words, and "it" can mean either the prompt or the approval. Acceptable: "So that prompt, and an approval reopened after its window closed, are opened in a tab at the URL the extension puts on the action. Whether a real toolbar click shows that page is not observable here."README.mdline 606 (Firefox suite): the sentence this PR changes, "It covers popup load, … driven through the real content script, background page and approval windows.", runs to about 70 words and chains the covered flows with commas. Acceptable: a short lead sentence, then a bulleted list of what the suite covers, with the closed approval window as its own bullet.README.mdline 2493 (TxApproval): "With several closed requests waiting" reads as requests that are finished yet still waiting. Acceptable: "When several requests wait with their windows closed, the toolbar button opens the oldest first."src/background/index.jsline 1481: "A site-connection or network-switch approval whose window closes is rejected, unless its popup connected its port." Read alone, it says a connected port spares the approval, yet the port's disconnect rejects it; the next sentences have to undo it. Acceptable: "This listener rejects a site-connection or network-switch approval whose window closes before its popup connected its port. Once the port is connected, the approval is left to the port."src/background/index.jsline 391:resetPopupUrl()now also points the toolbar popup at a closed approval, and its comment opens with "Set the toolbar popup back to the wallet." The window-close listener calls it right after marking an approval closed, to do the opposite of a reset. Acceptable: a name that says what it does, such asupdateToolbarPopup(), and a comment that opens on the rule: "Point the toolbar popup at the oldest pending approval whose window closed, or at the wallet when there is none."src/background/index.jsline 435: theabandonedResult()comment lists its cases as a closed site-connection or network-switch window, or a window that could not be opened. It leaves out the address switch, whichbroadcastAccountsChanged()also sends through it. For a transaction or signature approval, that is now one of the only two cases. Acceptable: name the address switch too, in a short sentence.tests/approvalWindow.test.jsline 182: "the site would then wait for good" is false. A lost rejection leaves the request pending, and the toolbar popup opens it again. Acceptable: "and the request would stay pending although the user rejected it."Follow-up note: the PR body runs to about 270 words, and "the old close-rejects behaviour" is a made-up term; "the old rule that a closed window rejects the request" says it plainly.
Judgement call: an address switch still answers 4001. I read that as within the definition of done, because the plan at #673 (comment) keeps it.
Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab instead), and the worker-restart case the PR body discloses.
Model: opus-5-5
7c5944b4d1todf0de00821df0de00821tof4d602d275Rework pushed.
README.md, limits of the Chrome suite: took the suggested wording.README.md, Firefox suite: a short lead sentence, then a bulleted list; the closed approval window is its own bullet.README.md, TxApproval: took the suggested wording.resetPopupUrl()is nowupdateToolbarPopup()at its definition, every call site and the comments; its comment opens on the rule.abandonedResult()comment now names the address switch, in its own sentence.tests/approvalWindow.test.js: took the suggested wording.updateToolbarPopup()once when the worker starts. A new unit test loads the background with the toolbar popup pointing at an approval and finds it pointing at the wallet. The "Unverified" line is gone from the PR body.Model: opus-5-5
Review: FAIL (needs-rework)
src/background/index.js, thewindows.onRemovedlistener andupdateToolbarPopup(): when a window closes while its approved transaction is still being verified or broadcast, the toolbar popup is pointed at that approval at once. Opened from the toolbar, it shows as a fresh request, with an empty password field, Confirm and Reject. Reject there is refused by the background ("This transaction is already being sent."), but the popup closes anyway. The user believes the request was rejected while the transaction goes out. The comments in this file call closing a window during a slow broadcast an ordinary event. Acceptable:updateToolbarPopup()skips an approval that an attempt holds, and runs again when an attempt claims or releases one. A unit test closes the window during an attempt and finds the toolbar popup opening the wallet until the attempt ends.Judgement call: an address switch still answers a waiting transaction or signature request with 4001, although the definition of done says only Cancel does. I read it as kept by the plan at #673 (comment); only the owner can change that.
Unverified: a real toolbar click on a reopened approval. Both browser suites open the toolbar's URL in a tab instead.
Model: opus-5-5
f4d602d275to6f87de84ceRework pushed.
updateToolbarPopup()skips an approval that an attempt holds, andclaimApproval()andreleaseApproval()call it. The toolbar popup opens the wallet until the attempt ends.README.mdsay so.Model: opus-5-5
Review: FAIL (needs-rework)
src/background/index.js, the comment overTX_APPROVAL_PENDING_MESSAGE(lines 163–166): "the other request is either being prepared or on screen" is now false. A transaction approval whose window closed keeps the slot while it is neither. Acceptable: "…so the other request is being prepared, is on screen, or waits with its window closed."README.mdlines 515–517 (the Chrome suite's dApp round trips): in "The suite then answers it from the page the toolbar button opens.", "it" can be read as the dApp page that the sentence before leaves "without an answer", and "the page" names two different pages in two sentences. Acceptable: "Closing a transaction or signature approval window is required to leave the dApp's request unanswered. The suite then opens that approval at the URL the toolbar button holds, and answers it there."Unverified: a real toolbar click on a reopened approval (both browser suites open the toolbar's URL in a tab), and a worker restart while an approval waits, which I read but did not run.
Model: opus-5-5
6f87de84cetobe1e058ef3Rework for #676 (comment):
TX_APPROVAL_PENDING_MESSAGEnow uses the suggested wording.Model: opus-5-5
Review: PASS
Model: opus-5-5