test: the state-recovery screen has no e2e coverage, so its behaviour under the real manifest CSP is unverified #361

New Issue

clawbot · 2026-08-23T18:41:59+02:00

clawbot commented

2026-08-23 18:41:59 +02:00

Follow-up from the review of #360 (#360 (comment)), which judged shipping without this acceptable but worth filing.

The recovery screen added by #311 is covered by jest driving the real src/popup/index.js over a DOM built from the real src/popup/index.html, with ids held against the markup by tests/popupElementIds.test.js. That is unusually strong for a unit test.

What it cannot cover is the browser-dependent part:

Whether the screen and its two controls work under the real manifest CSP. The blob download is already known to be best-effort because the manifest has no blob:, so the on-screen text box is the real export path — and it is untested in a real browser.
Whether the post-erase location.reload() actually lands on Welcome.

This is the one screen whose entire job is to appear when everything else is broken, so "it works in a DOM stub" is a weaker guarantee here than elsewhere.

Definition of done

An e2e case seeds a corrupt blob and asserts the popup shows view-state-recovery rather than a blank page.
The export text box is asserted to contain the verbatim stored record, in a real browser under the shipped CSP.
Typing the exact confirmation phrase erases and reloads to Welcome; a near-miss phrase erases nothing.
Runs in the existing pinned e2e harness. If it must be Chrome-only, say why in the PR body.
make check green and the e2e suite passes.

Follow-up from the review of https://git.eeqj.de/sneak/AutistMask/pulls/360 (https://git.eeqj.de/sneak/AutistMask/pulls/360#issuecomment-69222), which judged shipping without this acceptable but worth filing. The recovery screen added by https://git.eeqj.de/sneak/AutistMask/issues/311 is covered by jest driving the real `src/popup/index.js` over a DOM built from the real `src/popup/index.html`, with ids held against the markup by `tests/popupElementIds.test.js`. That is unusually strong for a unit test. What it cannot cover is the browser-dependent part: - Whether the screen and its two controls work under the **real manifest CSP**. The blob download is already known to be best-effort because the manifest has no `blob:`, so the on-screen text box is the real export path — and it is untested in a real browser. - Whether the post-erase `location.reload()` actually lands on Welcome. This is the one screen whose entire job is to appear when everything else is broken, so "it works in a DOM stub" is a weaker guarantee here than elsewhere. ## Definition of done - [ ] An e2e case seeds a corrupt blob and asserts the popup shows `view-state-recovery` rather than a blank page. - [ ] The export text box is asserted to contain the verbatim stored record, in a real browser under the shipped CSP. - [ ] Typing the exact confirmation phrase erases and reloads to Welcome; a near-miss phrase erases nothing. - [ ] Runs in the existing pinned e2e harness. If it must be Chrome-only, say why in the PR body. - [ ] `make check` green and the e2e suite passes.

clawbot referenced this issue

2026-08-23 19:00:39 +02:00

fix: version the stored profile, and give a record that cannot be read a way out (closes #311) #360

clawbot referenced this issue

2026-08-23 19:20:16 +02:00

fix: version the stored profile, and give a record that cannot be read a way out (closes #311) #360

clawbot referenced this issue

2026-08-23 20:02:57 +02:00

fix: version the stored profile, and give a record that cannot be read a way out (closes #311) #360

Sign in to join this conversation.