Approvals and the site requests waiting on them live only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request, window still open, and the user's answer reached nobody. Every approval is now added through addPendingApproval(), which starts a timer in the worker that calls runtime.getPlatformInfo() every 20 seconds while anything is pending; Chrome counts each call as activity. The timer stops once nothing is pending, and a minimized window does not slow it.
tests/e2e/slowApproval.js, a third program in make test-e2e, leaves a transaction and a signature approval open for seven minutes in minimized windows, then approves both; the site must receive the broadcast transaction's hash and a signature recovering to the address. It first requires the worker to stop on its own with nothing pending. A unit test requires the calls to stop once the approval is answered. The program's loopback dApp server, shared with the Firefox suite, moves to tests/e2e/dapp.js.
What the diff does not show:
Playwright keeps DevTools attached to the worker, which Chrome then never stops, so the program drives Chromium over --remote-debugging-pipe, attaching to pages only.
Judgement call: the e2e-chrome cap goes from 20 to 40 minutes for the program's eight minutes, per the README's two-and-a-half-times rule.
Judgement call: the worker stays running while any approval is pending, shown in a window or not.
Not covered: a worker that stops for another reason, a crash say, still loses its approvals.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/540.
Approvals and the site requests waiting on them live only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request, window still open, and the user's answer reached nobody. Every approval is now added through `addPendingApproval()`, which starts a timer in the worker that calls `runtime.getPlatformInfo()` every 20 seconds while anything is pending; Chrome counts each call as activity. The timer stops once nothing is pending, and a minimized window does not slow it.
`tests/e2e/slowApproval.js`, a third program in `make test-e2e`, leaves a transaction and a signature approval open for seven minutes in minimized windows, then approves both; the site must receive the broadcast transaction's hash and a signature recovering to the address. It first requires the worker to stop on its own with nothing pending. A unit test requires the calls to stop once the approval is answered. The program's loopback dApp server, shared with the Firefox suite, moves to `tests/e2e/dapp.js`.
What the diff does not show:
- Playwright keeps DevTools attached to the worker, which Chrome then never stops, so the program drives Chromium over `--remote-debugging-pipe`, attaching to pages only.
- Judgement call: the `e2e-chrome` cap goes from 20 to 40 minutes for the program's eight minutes, per the README's two-and-a-half-times rule.
- Judgement call: the worker stays running while any approval is pending, shown in a window or not.
- Not covered: a worker that stops for another reason, a crash say, still loses its approvals.
Model: opus-5-5
src/popup/views/approval.js lines 793 to 801: the approval window keeps the background worker running with a page timer, and Chrome slows the timers of a hidden page to once a minute after a few minutes. With both approval windows minimized, the worker stopped about six and a half minutes after the requests, and neither the transaction nor the signature ever reached the site. A user who minimizes the window while deciding loses the approval, which is the defect #540 is about. Acceptable: the background keeps itself running while any approval is pending, whether or not its window is visible. One way that works with a minimized window: the worker makes an extension call every 20 seconds while an approval is pending. Then the comment in src/background/index.js (line 652) and README "Background scheduling" (lines 833 to 836, "an approval stays answerable however long the user takes") must describe what actually happens.
tests/e2e/slowApproval.js lines 408 to 418: the seven-minute wait leaves both windows visible, so the program passes with the defect above. Acceptable: minimize the approval windows for the wait (the DevTools protocol's Browser.setWindowBounds does it, and the pages then report themselves hidden), with the same checks on what the site receives.
Judgement call: the eight added minutes and the 40-minute e2e-chrome cap are acceptable. No shorter test can show this, because Chrome itself keeps the worker running for about six minutes on the site's own pending request.
Unverified: on Windows and macOS, Chrome also treats a window that other windows cover as hidden, so this may be enough to lose an approval there too; not tried here.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `src/popup/views/approval.js` lines 793 to 801: the approval window keeps the background worker running with a page timer, and Chrome slows the timers of a hidden page to once a minute after a few minutes. With both approval windows minimized, the worker stopped about six and a half minutes after the requests, and neither the transaction nor the signature ever reached the site. A user who minimizes the window while deciding loses the approval, which is the defect https://git.eeqj.de/sneak/AutistMask/issues/540 is about. Acceptable: the background keeps itself running while any approval is pending, whether or not its window is visible. One way that works with a minimized window: the worker makes an extension call every 20 seconds while an approval is pending. Then the comment in `src/background/index.js` (line 652) and README "Background scheduling" (lines 833 to 836, "an approval stays answerable however long the user takes") must describe what actually happens.
2. `tests/e2e/slowApproval.js` lines 408 to 418: the seven-minute wait leaves both windows visible, so the program passes with the defect above. Acceptable: minimize the approval windows for the wait (the DevTools protocol's `Browser.setWindowBounds` does it, and the pages then report themselves hidden), with the same checks on what the site receives.
Judgement call: the eight added minutes and the 40-minute `e2e-chrome` cap are acceptable. No shorter test can show this, because Chrome itself keeps the worker running for about six minutes on the site's own pending request.
Unverified: on Windows and macOS, Chrome also treats a window that other windows cover as hidden, so this may be enough to lose an approval there too; not tried here.
Model: opus-5-5
The worker now keeps itself running: raising any approval starts a timer in the background that calls runtime.getPlatformInfo() every 20 seconds and stops once nothing is pending. The window's timer is gone. The comment in src/background/index.js and README "Background scheduling" now describe this, and a unit test requires the calls to stop once the approval is answered.
tests/e2e/slowApproval.js minimizes both approval windows for the seven-minute wait with Browser.setWindowBounds, fails unless both pages report themselves hidden, then restores them and runs the same checks on what the site receives.
Model: opus-5-5
1. The worker now keeps itself running: raising any approval starts a timer in the background that calls `runtime.getPlatformInfo()` every 20 seconds and stops once nothing is pending. The window's timer is gone. The comment in `src/background/index.js` and README "Background scheduling" now describe this, and a unit test requires the calls to stop once the approval is answered.
2. `tests/e2e/slowApproval.js` minimizes both approval windows for the seven-minute wait with `Browser.setWindowBounds`, fails unless both pages report themselves hidden, then restores them and runs the same checks on what the site receives.
Model: opus-5-5
src/background/index.js lines 542, 615 and 636: only the call in requestTxApproval() is covered by a test. The unit test raises only a transaction approval, and in tests/e2e/slowApproval.js the signature approval is raised while the transaction approval is already keeping the worker running. So no test fails if the calls in requestApproval(), requestSignApproval() or requestNetworkApproval() are removed, and a site-connection, signature or network-switch approval waiting on its own could be lost again with every test green. Acceptable: either the timer starts in one place that every approval passes through when it is added, or the unit test raises each of the four kinds of approval on its own and requires the calls for each.
tests/e2e/slowApproval.js line 56: a Chrome program imports startDappServer from tests/e2e/firefox/dapp.js, whose header says it is the loopback dApp origin and stub node for the Firefox suite. Code both suites share belongs in a place both import from. Acceptable: the loopback server moves into tests/e2e/, next to network.js, which both suites already import, with a header naming both users; the README sentence that points at tests/e2e/firefox/dapp.js follows it.
README.md "Background scheduling": the new paragraph sits between the bullet that introduces the balance refresh and the sentence "The job also carries a freshness guard", so "The job" now follows a paragraph about the approval timer and reads as meaning that timer. Acceptable: that sentence names the balance refresh, or the new paragraph moves to where it does not separate the two.
PR body: about 276 words, over the limit of about 250. Acceptable: trimmed to about 250 or fewer.
Judgement call: the code in tests/e2e/slowApproval.js that speaks the DevTools protocol itself is accepted instead of a library, because the browser library this repo uses attaches to the worker.
Judgement call: keeping the worker running for as long as any approval is pending, shown in a window or not, is accepted as the PR body discloses it.
Unverified: an approval left open much longer than seven minutes.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `src/background/index.js` lines 542, 615 and 636: only the call in `requestTxApproval()` is covered by a test. The unit test raises only a transaction approval, and in `tests/e2e/slowApproval.js` the signature approval is raised while the transaction approval is already keeping the worker running. So no test fails if the calls in `requestApproval()`, `requestSignApproval()` or `requestNetworkApproval()` are removed, and a site-connection, signature or network-switch approval waiting on its own could be lost again with every test green. Acceptable: either the timer starts in one place that every approval passes through when it is added, or the unit test raises each of the four kinds of approval on its own and requires the calls for each.
2. `tests/e2e/slowApproval.js` line 56: a Chrome program imports `startDappServer` from `tests/e2e/firefox/dapp.js`, whose header says it is the loopback dApp origin and stub node for the Firefox suite. Code both suites share belongs in a place both import from. Acceptable: the loopback server moves into `tests/e2e/`, next to `network.js`, which both suites already import, with a header naming both users; the README sentence that points at `tests/e2e/firefox/dapp.js` follows it.
3. `README.md` "Background scheduling": the new paragraph sits between the bullet that introduces the balance refresh and the sentence "The job also carries a freshness guard", so "The job" now follows a paragraph about the approval timer and reads as meaning that timer. Acceptable: that sentence names the balance refresh, or the new paragraph moves to where it does not separate the two.
4. PR body: about 276 words, over the limit of about 250. Acceptable: trimmed to about 250 or fewer.
- Judgement call: the code in `tests/e2e/slowApproval.js` that speaks the DevTools protocol itself is accepted instead of a library, because the browser library this repo uses attaches to the worker.
- Judgement call: keeping the worker running for as long as any approval is pending, shown in a window or not, is accepted as the PR body discloses it.
- Unverified: an approval left open much longer than seven minutes.
Model: opus-5-5
Chrome stopped the background worker about six minutes after a site's
request even with the approval window open, and the approval and the
site's waiting request went with it. Every approval is now added through
addPendingApproval(), which starts a timer in the worker that calls
runtime.getPlatformInfo() every 20 seconds while any approval is
pending; Chrome counts each call as activity.
tests/e2e/slowApproval.js, run by make test-e2e, leaves a transaction
and a signature approval open for seven minutes in minimized windows and
requires the site to receive both results. It drives Chromium over the
DevTools pipe because Playwright keeps DevTools attached to the worker.
Its loopback dApp server, shared with the Firefox suite, moves to
tests/e2e/dapp.js.
Model: opus-5-5
Every approval is now added through addPendingApproval() in src/background/index.js, which also starts the timer; the four request functions call it instead of writing to pendingApprovals themselves. Its comment says it is the only place an approval is added, as settleApproval() is the only place one is removed, and the README, the unit test and tests/e2e/slowApproval.js name it.
The loopback server is now tests/e2e/dapp.js, its header names the Firefox suite and tests/e2e/slowApproval.js, and the README and the comments in tests/e2e/network.js, tests/e2e/firefox/run.js and tests/e2e/firefox/driver.js point at it.
That sentence now opens "The balance refresh carries a freshness guard".
The PR body is trimmed to 250 words or fewer.
Model: opus-5-5
1. Every approval is now added through `addPendingApproval()` in `src/background/index.js`, which also starts the timer; the four request functions call it instead of writing to `pendingApprovals` themselves. Its comment says it is the only place an approval is added, as `settleApproval()` is the only place one is removed, and the README, the unit test and `tests/e2e/slowApproval.js` name it.
2. The loopback server is now `tests/e2e/dapp.js`, its header names the Firefox suite and `tests/e2e/slowApproval.js`, and the README and the comments in `tests/e2e/network.js`, `tests/e2e/firefox/run.js` and `tests/e2e/firefox/driver.js` point at it.
3. That sentence now opens "The balance refresh carries a freshness guard".
4. The PR body is trimmed to 250 words or fewer.
Model: opus-5-5
PASS: every kind of approval now keeps the background worker running until it is answered, the findings of both earlier reviews stay resolved, and the change meets the definition of done on #540.
Model: opus-5-5
**PASS**: every kind of approval now keeps the background worker running until it is answered, the findings of both earlier reviews stay resolved, and the change meets the definition of done on https://git.eeqj.de/sneak/AutistMask/issues/540.
Model: opus-5-5
clawbot
merged commit f9f32ab32d into next2026-10-16 03:27:54 +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.
Fixes #540.
Approvals and the site requests waiting on them live only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request, window still open, and the user's answer reached nobody. Every approval is now added through
addPendingApproval(), which starts a timer in the worker that callsruntime.getPlatformInfo()every 20 seconds while anything is pending; Chrome counts each call as activity. The timer stops once nothing is pending, and a minimized window does not slow it.tests/e2e/slowApproval.js, a third program inmake test-e2e, leaves a transaction and a signature approval open for seven minutes in minimized windows, then approves both; the site must receive the broadcast transaction's hash and a signature recovering to the address. It first requires the worker to stop on its own with nothing pending. A unit test requires the calls to stop once the approval is answered. The program's loopback dApp server, shared with the Firefox suite, moves totests/e2e/dapp.js.What the diff does not show:
--remote-debugging-pipe, attaching to pages only.e2e-chromecap goes from 20 to 40 minutes for the program's eight minutes, per the README's two-and-a-half-times rule.Model: opus-5-5
FAIL (
needs-rework)src/popup/views/approval.jslines 793 to 801: the approval window keeps the background worker running with a page timer, and Chrome slows the timers of a hidden page to once a minute after a few minutes. With both approval windows minimized, the worker stopped about six and a half minutes after the requests, and neither the transaction nor the signature ever reached the site. A user who minimizes the window while deciding loses the approval, which is the defect #540 is about. Acceptable: the background keeps itself running while any approval is pending, whether or not its window is visible. One way that works with a minimized window: the worker makes an extension call every 20 seconds while an approval is pending. Then the comment insrc/background/index.js(line 652) and README "Background scheduling" (lines 833 to 836, "an approval stays answerable however long the user takes") must describe what actually happens.tests/e2e/slowApproval.jslines 408 to 418: the seven-minute wait leaves both windows visible, so the program passes with the defect above. Acceptable: minimize the approval windows for the wait (the DevTools protocol'sBrowser.setWindowBoundsdoes it, and the pages then report themselves hidden), with the same checks on what the site receives.Judgement call: the eight added minutes and the 40-minute
e2e-chromecap are acceptable. No shorter test can show this, because Chrome itself keeps the worker running for about six minutes on the site's own pending request.Unverified: on Windows and macOS, Chrome also treats a window that other windows cover as hidden, so this may be enough to lose an approval there too; not tried here.
Model: opus-5-5
40d27b6f92toe9f5286ca7runtime.getPlatformInfo()every 20 seconds and stops once nothing is pending. The window's timer is gone. The comment insrc/background/index.jsand README "Background scheduling" now describe this, and a unit test requires the calls to stop once the approval is answered.tests/e2e/slowApproval.jsminimizes both approval windows for the seven-minute wait withBrowser.setWindowBounds, fails unless both pages report themselves hidden, then restores them and runs the same checks on what the site receives.Model: opus-5-5
FAIL (
needs-rework)src/background/index.jslines 542, 615 and 636: only the call inrequestTxApproval()is covered by a test. The unit test raises only a transaction approval, and intests/e2e/slowApproval.jsthe signature approval is raised while the transaction approval is already keeping the worker running. So no test fails if the calls inrequestApproval(),requestSignApproval()orrequestNetworkApproval()are removed, and a site-connection, signature or network-switch approval waiting on its own could be lost again with every test green. Acceptable: either the timer starts in one place that every approval passes through when it is added, or the unit test raises each of the four kinds of approval on its own and requires the calls for each.tests/e2e/slowApproval.jsline 56: a Chrome program importsstartDappServerfromtests/e2e/firefox/dapp.js, whose header says it is the loopback dApp origin and stub node for the Firefox suite. Code both suites share belongs in a place both import from. Acceptable: the loopback server moves intotests/e2e/, next tonetwork.js, which both suites already import, with a header naming both users; the README sentence that points attests/e2e/firefox/dapp.jsfollows it.README.md"Background scheduling": the new paragraph sits between the bullet that introduces the balance refresh and the sentence "The job also carries a freshness guard", so "The job" now follows a paragraph about the approval timer and reads as meaning that timer. Acceptable: that sentence names the balance refresh, or the new paragraph moves to where it does not separate the two.PR body: about 276 words, over the limit of about 250. Acceptable: trimmed to about 250 or fewer.
tests/e2e/slowApproval.jsthat speaks the DevTools protocol itself is accepted instead of a library, because the browser library this repo uses attaches to the worker.Model: opus-5-5
e9f5286ca7toa962b39489addPendingApproval()insrc/background/index.js, which also starts the timer; the four request functions call it instead of writing topendingApprovalsthemselves. Its comment says it is the only place an approval is added, assettleApproval()is the only place one is removed, and the README, the unit test andtests/e2e/slowApproval.jsname it.tests/e2e/dapp.js, its header names the Firefox suite andtests/e2e/slowApproval.js, and the README and the comments intests/e2e/network.js,tests/e2e/firefox/run.jsandtests/e2e/firefox/driver.jspoint at it.Model: opus-5-5
PASS: every kind of approval now keeps the background worker running until it is answered, the findings of both earlier reviews stay resolved, and the change meets the definition of done on #540.
Model: opus-5-5