An approval waiting for the user, and the site's request behind it, exist only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request with the approval window still open; an answer after that reached nobody and the site waited forever. The approval window now posts an empty message on its approval port every 20 seconds while it is open. Each message is an event, which keeps the worker running. The background ignores it.
tests/e2e/slowApproval.js, a third program in make test-e2e, leaves a transaction and a signature approval open for seven minutes, approves both, and requires the site to receive the broadcast transaction's hash and a signature that recovers to the address. It first requires the worker to stop on its own with nothing pending, so the wait cannot pass while something else holds the worker.
What the diff does not show:
It cannot live in tests/e2e/run.js: Playwright keeps DevTools attached to the worker, and Chrome never stops such a worker. The program starts Chromium itself and speaks the DevTools protocol over --remote-debugging-pipe, attaching to pages only.
Judgement call: the program adds about eight minutes, so the e2e-chrome cap goes from 20 to 40 minutes, per the README's two-and-a-half-times rule.
Judgement call: a window keeps the worker running for as long as it is open, the wait screen after a confirmed transaction included.
Not covered: a worker stopped for another reason, such as a crash, still loses the approvals open in it; the README says so.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/540.
An approval waiting for the user, and the site's request behind it, exist only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request with the approval window still open; an answer after that reached nobody and the site waited forever. The approval window now posts an empty message on its approval port every 20 seconds while it is open. Each message is an event, which keeps the worker running. The background ignores it.
`tests/e2e/slowApproval.js`, a third program in `make test-e2e`, leaves a transaction and a signature approval open for seven minutes, approves both, and requires the site to receive the broadcast transaction's hash and a signature that recovers to the address. It first requires the worker to stop on its own with nothing pending, so the wait cannot pass while something else holds the worker.
What the diff does not show:
- It cannot live in `tests/e2e/run.js`: Playwright keeps DevTools attached to the worker, and Chrome never stops such a worker. The program starts Chromium itself and speaks the DevTools protocol over `--remote-debugging-pipe`, attaching to pages only.
- Judgement call: the program adds about eight minutes, so the `e2e-chrome` cap goes from 20 to 40 minutes, per the README's two-and-a-half-times rule.
- Judgement call: a window keeps the worker running for as long as it is open, the wait screen after a confirmed transaction included.
- Not covered: a worker stopped for another reason, such as a crash, still loses the approvals open in it; the README says so.
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. The approval window now posts an
empty message on its approval port every 20 seconds while it is open;
each one is an event, which keeps the worker running.
tests/e2e/slowApproval.js, run by make test-e2e, leaves a transaction
and a signature approval open for seven minutes and requires the site
to receive both results. It drives Chromium over the DevTools pipe
without Playwright, because Playwright keeps DevTools attached to the
worker and Chrome then never stops it.
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
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.
An approval waiting for the user, and the site's request behind it, exist only in the background worker's memory. Chrome stopped the worker about six minutes after a site's request with the approval window still open; an answer after that reached nobody and the site waited forever. The approval window now posts an empty message on its approval port every 20 seconds while it is open. Each message is an event, which keeps the worker running. The background ignores it.
tests/e2e/slowApproval.js, a third program inmake test-e2e, leaves a transaction and a signature approval open for seven minutes, approves both, and requires the site to receive the broadcast transaction's hash and a signature that recovers to the address. It first requires the worker to stop on its own with nothing pending, so the wait cannot pass while something else holds the worker.What the diff does not show:
tests/e2e/run.js: Playwright keeps DevTools attached to the worker, and Chrome never stops such a worker. The program starts Chromium itself and speaks the DevTools protocol over--remote-debugging-pipe, attaching to pages only.e2e-chromecap goes from 20 to 40 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
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.