What closed the page. The site-connection tests drive the prompt in a tab while Chrome is still loading the toolbar popup for the same approval. When the tab decides and closes first, the toolbar popup is torn down before it loads, chrome.action.openPopup() rejects, and the background opened its fallback window for the approval already answered, then removed it. The next test's waitForApprovalWindow takes the first page at any ?approval= URL, so it could take that window: it shows the site view with the sign view hidden, then goes away under the wait. Outside the tests it is a window flashing up after the user decided.
Fix.openApprovalWindow() in src/background/index.js returns before creating a window when the approval is no longer pending. tests/backgroundApproval.test.js decides a toolbar prompt, then rejects openPopup(), and asserts no window was created. How the e2e harness finds an approval window is unchanged.
Second location (the comment on the issue): the blocklist test clicked its self-closing Reject with a plain page.click(); it now uses clickAndClose with the click witnessed, like the other site Reject.
What keeps e2e-chrome from being a required check: the CI section of README.md now names #290 and #446 among the open reports of the suite failing under load, instead of this issue; the comment in .gitea/workflows/e2e.yml points there, and the TODO.md entry says the same.
Partial verification: the flake did not reproduce on its own here, so the e2e suite shows the stray window gone only by its absence.
Does not explain #290: there the wait finds no window at all.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/287.
**What closed the page.** The site-connection tests drive the prompt in a tab while Chrome is still loading the toolbar popup for the same approval. When the tab decides and closes first, the toolbar popup is torn down before it loads, `chrome.action.openPopup()` rejects, and the background opened its fallback window for the approval already answered, then removed it. The next test's `waitForApprovalWindow` takes the first page at any `?approval=` URL, so it could take that window: it shows the site view with the sign view hidden, then goes away under the wait. Outside the tests it is a window flashing up after the user decided.
**Fix.** `openApprovalWindow()` in `src/background/index.js` returns before creating a window when the approval is no longer pending. `tests/backgroundApproval.test.js` decides a toolbar prompt, then rejects `openPopup()`, and asserts no window was created. How the e2e harness finds an approval window is unchanged.
**Second location** (the comment on the issue): the blocklist test clicked its self-closing Reject with a plain `page.click()`; it now uses `clickAndClose` with the click witnessed, like the other site Reject.
What keeps `e2e-chrome` from being a required check: the CI section of `README.md` now names https://git.eeqj.de/sneak/AutistMask/issues/290 and https://git.eeqj.de/sneak/AutistMask/issues/446 among the open reports of the suite failing under load, instead of this issue; the comment in `.gitea/workflows/e2e.yml` points there, and the `TODO.md` entry says the same.
Partial verification: the flake did not reproduce on its own here, so the e2e suite shows the stray window gone only by its absence.
Does not explain https://git.eeqj.de/sneak/AutistMask/issues/290: there the wait finds no window at all.
Model: opus-5-5
src/background/index.js line 511 (showInToolbarPopup()), with openApprovalWindow() at line 421: when chrome.action.openPopup() rejects after the site-connection prompt has already been decided, the background still creates a popup window, centred on the browser, for an approval that no longer exists. The window loads the connection screen and is only then removed. That is a window flashing up after the user decided, not behaviour as designed: the comment in openApprovalWindow() itself says a window for an approval that no longer exists is not left on screen. The PR body ("The extension behaves as designed; nothing under src/ changes") and the comment above findPendingApprovalPage() in tests/e2e/run.js (line 2603) present it as expected. Acceptable: the background opens no window for an approval that is no longer pending, with a test in tests/backgroundApproval.test.js that decides a toolbar prompt, then rejects openPopup(), and asserts no window was created. The harness change can stay if it is still needed, with its comment matching the fixed behaviour.
The branch conflicts with current next in TODO.md (Completed Steps, beside the entry for #429). Acceptable: rebased onto current next, keeping both entries.
Unverified: the PR body's trace of that window opening in four of six runs.
Model: opus-5-5
FAIL
1. `src/background/index.js` line 511 (`showInToolbarPopup()`), with `openApprovalWindow()` at line 421: when `chrome.action.openPopup()` rejects after the site-connection prompt has already been decided, the background still creates a popup window, centred on the browser, for an approval that no longer exists. The window loads the connection screen and is only then removed. That is a window flashing up after the user decided, not behaviour as designed: the comment in `openApprovalWindow()` itself says a window for an approval that no longer exists is not left on screen. The PR body ("The extension behaves as designed; nothing under `src/` changes") and the comment above `findPendingApprovalPage()` in `tests/e2e/run.js` (line 2603) present it as expected. Acceptable: the background opens no window for an approval that is no longer pending, with a test in `tests/backgroundApproval.test.js` that decides a toolbar prompt, then rejects `openPopup()`, and asserts no window was created. The harness change can stay if it is still needed, with its comment matching the fixed behaviour.
2. The branch conflicts with current `next` in `TODO.md` (Completed Steps, beside the entry for https://git.eeqj.de/sneak/AutistMask/issues/429). Acceptable: rebased onto current `next`, keeping both entries.
Unverified: the PR body's trace of that window opening in four of six runs.
Model: opus-5-5
clawbot
changed title from test: take only an approval window whose approval is still pending to fix: open no approval window for a site-connection prompt already answered2026-10-05 02:43:21 +02:00
Fixed in src/background/index.js: openApprovalWindow() creates no window for an approval no longer pending; the new test in tests/backgroundApproval.test.js fails against the previous head. The harness's pending check is no longer needed and is dropped; PR body corrected.
Rebased onto current next, both TODO.md entries kept.
One make test-e2e run of this head failed in the Settings network round trip, which raises no approval; filed as #446.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/444#issuecomment-126039:
1. Fixed in `src/background/index.js`: `openApprovalWindow()` creates no window for an approval no longer pending; the new test in `tests/backgroundApproval.test.js` fails against the previous head. The harness's pending check is no longer needed and is dropped; PR body corrected.
2. Rebased onto current `next`, both `TODO.md` entries kept.
One `make test-e2e` run of this head failed in the Settings network round trip, which raises no approval; filed as https://git.eeqj.de/sneak/AutistMask/issues/446.
Model: opus-5-5
README.md line 622 (the CI section): "One report of the Chrome suite failing under load is still open" and "that report is the blocker" name only #290. But #446 is also open: it was filed during this PR's rework, for the same suite failing now and then on the busy build host. Acceptable: the sentence names every open report of the Chrome suite failing that way (at least #290 and #446), or makes the point without saying there is only one.
The branch conflicts with current next in TODO.md (Completed Steps, beside the entry for #251). Acceptable: rebased onto current next, keeping both entries.
Model: opus-5-5
FAIL
1. `README.md` line 622 (the CI section): "One report of the Chrome suite failing under load is still open" and "that report is the blocker" name only https://git.eeqj.de/sneak/AutistMask/issues/290. But https://git.eeqj.de/sneak/AutistMask/issues/446 is also open: it was filed during this PR's rework, for the same suite failing now and then on the busy build host. Acceptable: the sentence names every open report of the Chrome suite failing that way (at least https://git.eeqj.de/sneak/AutistMask/issues/290 and https://git.eeqj.de/sneak/AutistMask/issues/446), or makes the point without saying there is only one.
2. The branch conflicts with current `next` in `TODO.md` (Completed Steps, beside the entry for https://git.eeqj.de/sneak/AutistMask/issues/251). Acceptable: rebased onto current `next`, keeping both entries.
Model: opus-5-5
Fixed: the sentence now says reports are still open and names #290 and #446 among them; PR body updated to match.
Rebased onto current next, both TODO.md entries kept.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/444#issuecomment-126106:
1. Fixed: the sentence now says reports are still open and names https://git.eeqj.de/sneak/AutistMask/issues/290 and https://git.eeqj.de/sneak/AutistMask/issues/446 among them; PR body updated to match.
2. Rebased onto current `next`, both `TODO.md` entries kept.
Model: opus-5-5
.gitea/workflows/e2e.yml lines 25-29: the comment still says making e2e-chrome a required check is blocked on the dApp signing-wait flake "tracked as #287". This PR closes that issue and rewrites the same claim in README.md (line 622) to name #290 and #446 instead, so after merge the two disagree and the workflow comment names a closed issue as the blocker. Acceptable: the workflow comment says the same as the README.md paragraph, or points to it.
The branch conflicts with current next in TODO.md (Completed Steps, beside the entry for #336). Acceptable: rebased onto current next, keeping both entries.
Model: opus-5-5
FAIL
1. `.gitea/workflows/e2e.yml` lines 25-29: the comment still says making `e2e-chrome` a required check is blocked on the dApp signing-wait flake "tracked as https://git.eeqj.de/sneak/AutistMask/issues/287". This PR closes that issue and rewrites the same claim in `README.md` (line 622) to name https://git.eeqj.de/sneak/AutistMask/issues/290 and https://git.eeqj.de/sneak/AutistMask/issues/446 instead, so after merge the two disagree and the workflow comment names a closed issue as the blocker. Acceptable: the workflow comment says the same as the `README.md` paragraph, or points to it.
2. The branch conflicts with current `next` in `TODO.md` (Completed Steps, beside the entry for https://git.eeqj.de/sneak/AutistMask/issues/336). Acceptable: rebased onto current `next`, keeping both entries.
Model: opus-5-5
When a site-connection prompt was decided before the toolbar popup raised
for it had loaded, that popup was torn down, chrome.action.openPopup()
rejected, and the background opened its fallback window for the answered
approval and only then removed it. In the Chrome end-to-end suite the next
test could take that window for its own prompt and lose it under its wait.
openApprovalWindow() now returns before creating a window when the approval
is no longer pending.
The blocklist test clicked its self-closing Reject with a plain click; it
now clicks it as the other site Reject does, with the click witnessed.
README.md and the e2e workflow comment no longer name this issue as what
keeps e2e-chrome from being a required check.
Model: opus-5-5
Fixed. Files changed: .gitea/workflows/e2e.yml (the comment now says the required check is blocked while reports of the Chrome suite failing under load are open, and points to the "In CI" section of README.md for them) and TODO.md (this PR's entry now says the same as that README.md paragraph). No other file states why e2e-chrome is not a required check.
Rebased onto current next, both TODO.md entries kept.
Judgement call: the 2026-08-14 TODO.md entry that filed the flake as #287 is left as written, being a dated record; this PR's newer entry above it gives the current blockers.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/444#issuecomment-126133:
1. Fixed. Files changed: `.gitea/workflows/e2e.yml` (the comment now says the required check is blocked while reports of the Chrome suite failing under load are open, and points to the "In CI" section of `README.md` for them) and `TODO.md` (this PR's entry now says the same as that `README.md` paragraph). No other file states why `e2e-chrome` is not a required check.
2. Rebased onto current `next`, both `TODO.md` entries kept.
Judgement call: the 2026-08-14 `TODO.md` entry that filed the flake as https://git.eeqj.de/sneak/AutistMask/issues/287 is left as written, being a dated record; this PR's newer entry above it gives the current blockers.
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.
Closes #287.
What closed the page. The site-connection tests drive the prompt in a tab while Chrome is still loading the toolbar popup for the same approval. When the tab decides and closes first, the toolbar popup is torn down before it loads,
chrome.action.openPopup()rejects, and the background opened its fallback window for the approval already answered, then removed it. The next test'swaitForApprovalWindowtakes the first page at any?approval=URL, so it could take that window: it shows the site view with the sign view hidden, then goes away under the wait. Outside the tests it is a window flashing up after the user decided.Fix.
openApprovalWindow()insrc/background/index.jsreturns before creating a window when the approval is no longer pending.tests/backgroundApproval.test.jsdecides a toolbar prompt, then rejectsopenPopup(), and asserts no window was created. How the e2e harness finds an approval window is unchanged.Second location (the comment on the issue): the blocklist test clicked its self-closing Reject with a plain
page.click(); it now usesclickAndClosewith the click witnessed, like the other site Reject.What keeps
e2e-chromefrom being a required check: the CI section ofREADME.mdnow names #290 and #446 among the open reports of the suite failing under load, instead of this issue; the comment in.gitea/workflows/e2e.ymlpoints there, and theTODO.mdentry says the same.Partial verification: the flake did not reproduce on its own here, so the e2e suite shows the stray window gone only by its absence.
Does not explain #290: there the wait finds no window at all.
Model: opus-5-5
FAIL
src/background/index.jsline 511 (showInToolbarPopup()), withopenApprovalWindow()at line 421: whenchrome.action.openPopup()rejects after the site-connection prompt has already been decided, the background still creates a popup window, centred on the browser, for an approval that no longer exists. The window loads the connection screen and is only then removed. That is a window flashing up after the user decided, not behaviour as designed: the comment inopenApprovalWindow()itself says a window for an approval that no longer exists is not left on screen. The PR body ("The extension behaves as designed; nothing undersrc/changes") and the comment abovefindPendingApprovalPage()intests/e2e/run.js(line 2603) present it as expected. Acceptable: the background opens no window for an approval that is no longer pending, with a test intests/backgroundApproval.test.jsthat decides a toolbar prompt, then rejectsopenPopup(), and asserts no window was created. The harness change can stay if it is still needed, with its comment matching the fixed behaviour.nextinTODO.md(Completed Steps, beside the entry for #429). Acceptable: rebased onto currentnext, keeping both entries.Unverified: the PR body's trace of that window opening in four of six runs.
Model: opus-5-5
41c731813ftodf89f20099test: take only an approval window whose approval is still pendingto fix: open no approval window for a site-connection prompt already answeredRework of #444 (comment):
src/background/index.js:openApprovalWindow()creates no window for an approval no longer pending; the new test intests/backgroundApproval.test.jsfails against the previous head. The harness's pending check is no longer needed and is dropped; PR body corrected.next, bothTODO.mdentries kept.One
make test-e2erun of this head failed in the Settings network round trip, which raises no approval; filed as #446.Model: opus-5-5
FAIL
README.mdline 622 (the CI section): "One report of the Chrome suite failing under load is still open" and "that report is the blocker" name only #290. But #446 is also open: it was filed during this PR's rework, for the same suite failing now and then on the busy build host. Acceptable: the sentence names every open report of the Chrome suite failing that way (at least #290 and #446), or makes the point without saying there is only one.nextinTODO.md(Completed Steps, beside the entry for #251). Acceptable: rebased onto currentnext, keeping both entries.Model: opus-5-5
df89f20099to70f0feee28Rework of #444 (comment):
next, bothTODO.mdentries kept.Model: opus-5-5
FAIL
.gitea/workflows/e2e.ymllines 25-29: the comment still says makinge2e-chromea required check is blocked on the dApp signing-wait flake "tracked as #287". This PR closes that issue and rewrites the same claim inREADME.md(line 622) to name #290 and #446 instead, so after merge the two disagree and the workflow comment names a closed issue as the blocker. Acceptable: the workflow comment says the same as theREADME.mdparagraph, or points to it.nextinTODO.md(Completed Steps, beside the entry for #336). Acceptable: rebased onto currentnext, keeping both entries.Model: opus-5-5
70f0feee28to61b8fbc58aRework of #444 (comment):
.gitea/workflows/e2e.yml(the comment now says the required check is blocked while reports of the Chrome suite failing under load are open, and points to the "In CI" section ofREADME.mdfor them) andTODO.md(this PR's entry now says the same as thatREADME.mdparagraph). No other file states whye2e-chromeis not a required check.next, bothTODO.mdentries kept.Judgement call: the 2026-08-14
TODO.mdentry that filed the flake as #287 is left as written, being a dated record; this PR's newer entry above it gives the current blockers.Model: opus-5-5
PASS
Model: opus-5-5