build: run the browser e2e suites in CI (closes #259)

Nothing automatic ran either e2e suite, so every browser-level guarantee in this
wallet -- WebAssembly under the shipped CSP, the recovery-phrase and private-key
DOM wipes, the ConfirmTx spend gate, the dApp approval round trips -- held only
when a human or an agent remembered to run it by hand.

.gitea/workflows/e2e.yml adds two jobs, e2e-chrome and e2e-firefox, one per
browser so a Chrome failure cannot hide the Firefox result. They are separate
from the check workflow: REPO_POLICIES.md caps make test at 20 seconds and
script/cibuild is a docker build whose Dockerfile runs make check, so neither the
cap nor the local fast path is touched. make check is byte-for-byte unchanged.

Neither suite could run on the runner as it stood, and the reason is not
docker-in-docker. The runner executes a job inside a container against the HOST's
docker daemon, and the job's checkout lives on a docker volume rather than a host
path, so `docker run -v "$PWD:/work"` is resolved by the host, silently succeeds
and mounts an empty directory -- measured on this runner. The runner image's node
is also too old to install this repo's dependencies. Both suites therefore ship
the repo to the daemon as a build context and build the extension inside the
pinned image, which leaves docker as the only prerequisite on a runner or a
laptop. The suites themselves are unchanged; only how the repo reaches the
container is.

Both scripts now build with --iidfile and run the image by ID rather than by tag,
so two clones running a suite at once on the same host cannot swap it under each
other.

The jobs report, they do not gate. Whether a check blocks a merge is Gitea branch
protection, which this repo does not configure, so a failure is a red mark a
reviewer must account for. Nothing can pass vacuously: no continue-on-error, no
`|| true`, and both scripts exit non-zero when docker is missing, when the image
build fails and when the browser fails to start.

Wiring this up measured something that has to be said rather than absorbed: the
Chrome suite is flaky under load. Two of six runs of unmutated code on a loaded
machine lost the approval popup out from under the dApp signing wait. It is
filed as #287 and not papered over here -- no retry wrapper, no longer timeout,
no weakened assertion -- and it is the reason e2e-chrome cannot become a
required check yet. README and the workflow say so where a reader meets them.

.gitea/workflows/e2e.yml

@@ -0,0 +1,49 @@
+name: e2e
+on: [push]
+
+# The browser end-to-end suites, one job per browser, deliberately kept out
+# of the check workflow: REPO_POLICIES.md caps make test at 20 seconds and
+# script/cibuild is a plain `docker build .` whose Dockerfile runs
+# make check, so folding a browser suite into either would blow that cap
+# and slow the local fast path. Before this workflow every browser-level
+# guarantee in this repo held only when a human remembered to run it.
+#
+# One job per browser rather than two steps in one job, so a Chrome failure
+# does not hide the Firefox result.
+#
+# Each job is one script and nothing else. Both scripts need docker and
+# nothing else — they deliver the repo to the daemon as a build context and
+# build the extension inside the pinned image — which is what makes them
+# runnable here at all: the runner executes the job in a container against
+# the host's docker socket, so a `-v "$PWD:/work"` source path is resolved
+# by the host daemon and mounts an empty directory, and the runner image's
+# node is too old to install this repo's dependencies.
+#
+# These jobs REPORT, they do not gate. Whether a check blocks a merge is
+# Gitea branch protection, which this repo does not configure, so a failure
+# here is a red mark a reviewer has to account for rather than a hard
+# block. Making e2e-chrome a required check is blocked on the measured
+# flake in the dApp signing wait -- two of six runs of unmutated code on a
+# loaded machine -- tracked as
+# https://git.eeqj.de/sneak/AutistMask/issues/287. A gate that fails at
+# random teaches people to merge past red.
+#
+# Nothing here may pass vacuously. There is no continue-on-error and no
+# `|| true`. Both scripts exit non-zero when docker is missing, when the
+# image build fails, and when the browser fails to start; the Chrome
+# harness aborts the suite outright if its network interception is not in
+# effect.
+jobs:
+    e2e-chrome:
+        runs-on: ubuntu-latest
+        steps:
+            # actions/checkout v4.2.2, 2026-02-22
+            - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+            - run: script/test-e2e
+
+    e2e-firefox:
+        runs-on: ubuntu-latest
+        steps:
+            # actions/checkout v4.2.2, 2026-02-22
+            - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+            - run: script/test-e2e-firefox

README.md

@@ -83,10 +83,11 @@ provide:
   git pre-commit hook
 - `script/projectname` — print the project name (used for the Docker image tag)
 - `script/test` — run the test suite (jest)
-- `script/test-e2e` — run the Chrome browser end-to-end suite (docker required;
+- `script/test-e2e` — run the Chrome browser end-to-end suite (docker is the
-  see [End-to-End Tests](#end-to-end-tests))
+  only prerequisite: it builds a pinned image that carries the repo and a fresh
-- `script/test-e2e-firefox` — run the Firefox browser end-to-end suite (docker
+  extension build, see [End-to-End Tests](#end-to-end-tests))
-  required; builds its own pinned image, see
+- `script/test-e2e-firefox` — run the Firefox browser end-to-end suite (same,
+  against an image with a pinned Firefox and geckodriver, see
   [End-to-End Tests](#end-to-end-tests))
 - `script/lint` — run the linter
 - `script/fmt` — format all files (writes)
@@ -136,11 +137,12 @@ are outside `make check`.
 
 `make test-e2e` builds `dist/chrome/` and drives the **real popup in a real
 Chrome**, loaded as an unpacked MV3 extension inside a pinned
-`mcr.microsoft.com/playwright` container (pinned by digest in `script/test-e2e`;
+`mcr.microsoft.com/playwright` container (pinned by digest in
-docker is required and the suite fails loudly rather than skipping if it is
+`tests/e2e/Dockerfile`, which is also where the extension is built; docker is
-unavailable). The suite lives in `tests/e2e/` and is driven by
+required and the suite fails loudly rather than skipping if it is unavailable).
-`playwright-core`, whose version must stay matched to the container's Playwright
+The suite lives in `tests/e2e/` and is driven by `playwright-core`, whose
-version — the browsers ship inside the image.
+version must stay matched to the container's Playwright version — the browsers
+ship inside the image.
 
 It covers popup load, WebAssembly compilation under the shipped CSP (see
 [Content Security Policy](#content-security-policy)), wallet creation through
@@ -320,9 +322,46 @@ Two limits are worth knowing, both real differences from the Chrome suite:
 Neither `make test-e2e` nor `make test-e2e-firefox` is part of `make check` or
 `make test`. `REPO_POLICIES.md` caps `make test` at 20 seconds and a browser
 suite does not fit; nothing in `tests/e2e/` is named `*.test.js`, so jest cannot
-pick it up either. Neither is wired into the Gitea workflow yet —
+pick it up either. Run them locally before changing anything under
-docker-in-docker in CI is a separate question. Run them locally before changing
+`src/popup/views/`.
-anything under `src/popup/views/`.
+
+### In CI
+
+`.gitea/workflows/e2e.yml` runs both suites on every push, as two jobs —
+`e2e-chrome` and `e2e-firefox` — separate from the `check` workflow, so the
+20-second `make test` cap and the local fast path are untouched. Each job is a
+checkout and the matching `script/` entrypoint, nothing else.
+
+Docker is the only thing either job needs from the runner, and that is not an
+accident. The runner executes a job inside a container against the **host's**
+docker daemon, so a `docker run -v "$PWD:/work"` source path is resolved by the
+host and mounts an empty directory, and the runner image's node is too old to
+install this repo's dependencies. Both suites therefore ship the repo to the
+daemon as a build context and build the extension inside the image, which works
+identically on a laptop.
+
+The jobs **report, they do not gate.** A failure is a red mark against the
+commit that a reviewer has to account for, not a hard block: whether a check
+blocks a merge is Gitea branch protection, which this repo does not configure.
+
+That is not only a statement about configuration. The Chrome suite is
+**measurably flaky under load** — two of six runs of unmutated code on a busy
+machine lost the approval popup out from under the dApp signing wait, always in
+the `#183` section, tracked as
+[#287](https://git.eeqj.de/sneak/AutistMask/issues/287). So a red `e2e-chrome`
+has to be read before it is believed, and that flake is the blocker to ever
+making this a required check. Do not answer it with a retry wrapper: a suite
+that reruns until it is green stops being evidence.
+
+Nothing in either job can pass vacuously. There is no `continue-on-error` and no
+`|| true`; both scripts exit non-zero when docker is missing, when the image
+build fails, and when the browser fails to start; the Chrome harness aborts the
+suite outright if its network interception is not in effect.
+
+Measured on this repo's runner: `e2e-chrome` about 1m55s cold, almost all of it
+the one-time pull of the pinned ~800MB Playwright layer, and well under a minute
+once that layer is cached. `e2e-firefox` about 1m05s cold, and it caches its
+Firefox and geckodriver downloads the same way.
 
 ## Rationale
 
@@ -638,6 +677,21 @@ ExportPrivKey and ShowRecoveryPhrase — are deliberately absent from that list,
 so the popup can never reopen onto one of them with no password prompt in front
 of it.
 
+A reopened popup renders the wallet list and the one screen it restores onto,
+and nothing else, so every screen on the stack behind that one is still the
+blank template from `index.html`. "Back" therefore renders its target rather
+than only unhiding it, through the same dispatch and data guards as the restore
+(`src/popup/viewRouter.js`), and falls back to Home when the state the target
+would render is gone.
+
+It renders only a screen this page load has not rendered yet. Forward navigation
+renders as it goes, and `viewRouter.js` records every screen that reaches
+`showView()`, so "Back" onto a screen already on the page unhides it and nothing
+more — rendering it a second time would re-fetch and overwrite what it holds,
+such as an edit typed into Settings and not yet saved. Home is the one screen
+"Back" always re-renders, so the wallet list reflects anything that changed
+while the user was away from it.
+
 Every screen that holds secret material in the page registers a cleanup with
 `onViewLeave()` (`src/popup/views/helpers.js`), which `showView()` runs on every
 exit from that screen rather than only on its "Back" button, so nothing secret

TODO.md

@@ -33,7 +33,8 @@ The backlog lives on the
 authoritative; this file does not duplicate it. Full policy file set present.
 Real-browser end-to-end suites (`make test-e2e` for Chrome,
 `make test-e2e-firefox` for Firefox) now sit alongside `make check`, which
-cannot see a runtime `ReferenceError` in a popup view.
+cannot see a runtime `ReferenceError` in a popup view, and
+`.gitea/workflows/e2e.yml` runs both of them on every push.
 
 # Next Step
 
@@ -45,6 +46,55 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-14: CI runs the browser end-to-end suites. `.gitea/workflows/e2e.yml`
+  runs `script/test-e2e` and `script/test-e2e-firefox` as two jobs on every
+  push, separate from `check`, so `make check` and its 20-second `make test` cap
+  are untouched. Every browser-level guarantee in this repo — the WASM-under-CSP
+  check, the recovery-phrase and private-key DOM wipes, the ConfirmTx spend
+  gate, the dApp approval round trips — was enforced only when a human
+  remembered to run it by hand. The suites could not run on the runner as they
+  stood: the runner executes a job in a container against the host's docker
+  daemon, so `docker run -v "$PWD:/work"` mounts an empty directory (measured),
+  and the runner image's node cannot install this repo's dependencies. Both
+  suites now ship the repo to the daemon as a build context and build the
+  extension inside the pinned image, so docker is the only prerequisite on a
+  runner or a laptop, and both run the image by ID rather than by tag so
+  concurrent clones cannot swap it. The jobs report rather than gate — this repo
+  configures no branch protection, and the Chrome suite is measurably flaky
+  under load, filed as [#287](https://git.eeqj.de/sneak/AutistMask/issues/287)
+  rather than papered over
+  ([#259](https://git.eeqj.de/sneak/AutistMask/issues/259)).
+- 2026-08-12: EIP-1193 error codes now reach the page. `src/content/inpage.js`
+  rebuilt every failure as `new Error(error.message)`, so the code the
+  background produced and the content script relayed intact was dropped in the
+  last hop and a dApp checking `err.code === 4001` saw `undefined` — a wallet
+  the user deliberately declined was indistinguishable from one that broke. The
+  provider now rejects with a `ProviderRpcError` carrying `code` and, where the
+  boundary sent one, `data`, passed through verbatim rather than matched against
+  a list, so 4001, 4100 and 4902 all arrive and a future code needs no edit
+  here. An error the background sent with no code stays a plain `Error` with no
+  `code` property, and `message` is unchanged in every case. All four request
+  entry points (`request`, `enable`, `send`, `sendAsync`) are covered by
+  `tests/inpageErrors.test.js`, and the e2e probe that printed the missing code
+  now requires it on the page's Error as well as on the wire, for all four
+  rejected flows ([#274](https://git.eeqj.de/sneak/AutistMask/issues/274)).
+- 2026-08-12: "Back" now renders the screen it lands on instead of only unhiding
+  it. A reopened popup renders the wallet list and the one screen it restores
+  onto, so every screen further down the stack was still the blank template from
+  `index.html`, and Back walked straight onto it — an empty address, no
+  balances, no QR code. The Back path now goes through the same per-view
+  dispatch and data guards as the restore (`src/popup/viewRouter.js`, shared
+  with `restoreView()`), falling back to Home when the state the target would
+  render is gone. It renders only a view this page load has not rendered yet:
+  `viewRouter.js` records every view that reaches `showView()`, which is where
+  forward navigation and the restore both end, so Back onto a view already on
+  the page unhides it and nothing more. That is what keeps a second render from
+  re-fetching and overwriting what the view holds — an unsaved edit in Settings,
+  a transaction list already loaded. Home is the exception and is always
+  re-rendered, as it was before. Covered by unit tests on the real `goBack()`
+  and by three end-to-end cases against the real popup, each demonstrated
+  failing on the unfixed build
+  ([#268](https://git.eeqj.de/sneak/AutistMask/issues/268)).
 - 2026-08-12: `KNOWN_SYMBOLS` now maps a symbol to the set of contract addresses
   that bear it, not to one of them. A ticker is not unique: seven of the 512
   bundled tokens — `FRAX`, `REUSD`, `TON`, `EURE`, `MSUSD`, `MUSD` and `JPYC` —
@@ -337,9 +387,5 @@ tracker.
 - Pre-1.0 security review of the extension (key handling, DEBUG mode policy, RPC
   input validation) before any 1.0rc tag. Individual filed issues are parts of
   it, but the review is broader than any of them.
-- Decide whether docker-in-docker makes `make test-e2e` and
-  `make test-e2e-firefox` runnable in the Gitea workflow. Extending the Chrome
-  suite itself is tracked as
-  [#183](https://git.eeqj.de/sneak/AutistMask/issues/183).
 - Cut 1.0.0 once the milestone is empty, then continue tagging as milestones
   land.

script/test-e2e

@@ -7,17 +7,29 @@
 # caps make test at 20 seconds and a browser suite does not fit. Run it
 # yourself before touching popup views; it is the only check that can see
 # a used-but-not-imported identifier blow up at runtime.
+# .gitea/workflows/e2e.yml also runs it on every push, in a job separate
+# from check so that cap and the local fast path both stay intact.
+#
+# Docker is the only prerequisite. The repo reaches the container as a
+# build context and the extension is built inside it (see
+# tests/e2e/Dockerfile), so nothing here depends on the node, yarn or make
+# on the machine that starts the run. That is not a convenience: a bind
+# mount cannot work under Gitea Actions, and the runner image's node is too
+# old to install this repo's dependencies.
 set -eu
 
-ROOT="$(cd "$(dirname "$0")/.." && pwd -P)"
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd -P)"
+ROOT="$(cd "$SCRIPT_DIR/.." && pwd -P)"
 
-# mcr.microsoft.com/playwright:v1.56.0-noble, 2026-08-09
+IMAGE="$("$SCRIPT_DIR/projectname")-e2e-chrome"
-#
+
-# The playwright-core devDependency is pinned to the matching Playwright
+IIDFILE=""
-# version (1.56.0) and the two must be bumped together: the browsers ship
+
-# inside this image, and playwright-core looks for the exact browser
+cleanup() {
-# revision its own version expects. A mismatch fails at launch.
+    if [ -n "$IIDFILE" ]; then
-IMAGE="mcr.microsoft.com/playwright@sha256:35246d87a7c88ea9b771c65d33171b2611b02a8253b4b12ce6f94376c55f99f2"
+        rm -f "$IIDFILE"
+    fi
+}
 
 main() {
     cd "$ROOT"
@@ -27,14 +39,23 @@ main() {
         exit 1
     fi
 
-    echo "Building extension for e2e..."
+    IIDFILE="$(mktemp)"
-    yarn run build 2>&1
+    trap cleanup EXIT
+    trap 'cleanup; exit 130' INT TERM
+
+    echo "Building the Chrome e2e image (extension included)..."
+    docker build --iidfile "$IIDFILE" -t "$IMAGE" -f tests/e2e/Dockerfile .
 
     echo "Running e2e suite in the pinned Playwright container..."
+    # The image is run by ID, not by tag: where two clones of this repo run
+    # the suite at once, the other build can move the tag between this
+    # build and this run, and the suite would then silently test the other
+    # checkout.
+    #
     # --ipc=host: Chromium's shared-memory needs more than the default
     #   64MB /dev/shm or renderers crash.
-    # --user: keep files the suite touches owned by the caller, not root.
+    # HOME=/tmp: the image's root home is not a reliable place for the
-    # HOME=/tmp: the mapped uid has no home directory in the image.
+    #   browser profile.
     # PW_EXPERIMENTAL_SERVICE_WORKER_NETWORK_EVENTS=1: without it,
     #   ctx.route() intercepts page requests only, and every fetch made by
     #   the MV3 background service worker — including the phishing
@@ -51,13 +72,10 @@ main() {
     #   on a deliberate bump.
     docker run --rm \
         --ipc=host \
-        --user "$(id -u):$(id -g)" \
         -e HOME=/tmp \
         -e PW_EXPERIMENTAL_SERVICE_WORKER_NETWORK_EVENTS=1 \
         -e "E2E_TRACE_NETWORK=${E2E_TRACE_NETWORK:-0}" \
-        -v "$ROOT:/work" \
+        "$(cat "$IIDFILE")" \
-        -w /work \
-        "$IMAGE" \
         node tests/e2e/run.js
 }
 

script/test-e2e-firefox

@@ -5,12 +5,17 @@
 #
 # Deliberately NOT called by script/check or script/test, for the same
 # reason as the Chrome suite: REPO_POLICIES.md caps make test at 20 seconds
-# and a browser suite does not fit.
+# and a browser suite does not fit. .gitea/workflows/e2e.yml also runs it
+# on every push, in a job separate from check.
 #
-# Unlike script/test-e2e this builds its image locally, because no
+# Unlike script/test-e2e this builds its base image locally, because no
 # published image carries both a pinned Firefox and a matching geckodriver.
 # All three external artifacts are pinned by digest inside the Dockerfile;
-# see tests/e2e/firefox/Dockerfile.
+# see tests/e2e/firefox/Dockerfile, which also explains why the repo and
+# the extension build are baked into the image rather than mounted.
+#
+# Docker is the only prerequisite: nothing here depends on the node, yarn
+# or make on the machine that starts the run.
 set -eu
 
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd -P)"
@@ -18,6 +23,14 @@ ROOT="$(cd "$SCRIPT_DIR/.." && pwd -P)"
 
 IMAGE="$("$SCRIPT_DIR/projectname")-e2e-firefox"
 
+IIDFILE=""
+
+cleanup() {
+    if [ -n "$IIDFILE" ]; then
+        rm -f "$IIDFILE"
+    fi
+}
+
 main() {
     cd "$ROOT"
 
@@ -26,16 +39,20 @@ main() {
         exit 1
     fi
 
-    echo "Building extension for e2e..."
+    IIDFILE="$(mktemp)"
-    yarn run build 2>&1
+    trap cleanup EXIT
+    trap 'cleanup; exit 130' INT TERM
 
-    # The build context is tests/e2e/firefox/ and holds nothing but the
+    echo "Building the pinned Firefox e2e image (extension included)..."
-    # Dockerfile: the harness itself arrives over the bind mount below, so
+    docker build --iidfile "$IIDFILE" -t "$IMAGE" \
-    # editing it never invalidates an image layer.
+        -f tests/e2e/firefox/Dockerfile .
-    echo "Building the pinned Firefox e2e image..."
-    docker build -t "$IMAGE" "$ROOT/tests/e2e/firefox"
 
     echo "Running the Firefox e2e suite..."
+    # The image is run by ID, not by tag: where two clones of this repo run
+    # the suite at once, the other build can move the tag between this
+    # build and this run, and the suite would then silently test the other
+    # checkout.
+    #
     # --shm-size=1g: Firefox needs more than the default 64MB /dev/shm.
     # --network none: the suite stubs nothing, so this is what keeps the
     #   run offline and deterministic. The extension swallows its own
@@ -43,8 +60,8 @@ main() {
     #   network note in README.md. Weaker than the Chrome suite's
     #   fixture interception, and honestly so — it proves no request
     #   escaped, but it cannot report which ones were attempted.
-    # --user: keep files the suite touches owned by the caller, not root.
+    # HOME=/tmp: the image's root home is not a reliable place for the
-    # HOME=/tmp: the mapped uid has no home directory in the image.
+    #   browser profile.
     #
     # No --privileged. Firefox's sandbox logs
     # "CanCreateUserNamespace() clone() failure: EPERM" on startup here;
@@ -52,11 +69,8 @@ main() {
     docker run --rm \
         --shm-size=1g \
         --network none \
-        --user "$(id -u):$(id -g)" \
         -e HOME=/tmp \
-        -v "$ROOT:/work" \
+        "$(cat "$IIDFILE")" \
-        -w /work \
-        "$IMAGE" \
         node tests/e2e/firefox/run.js dist/firefox
 }
 

src/content/inpage.js

@@ -11,6 +11,39 @@
     let nextId = 1;
     const pending = {};
 
+    // EIP-1193 ProviderRpcError: `code`, `message`, optional `data`. A class
+    // rather than properties bolted onto an Error because this object crosses
+    // no boundary after construction — it is built in the page's own realm and
+    // handed straight to the caller's catch — so the prototype survives and
+    // `error.name` is a stable thing for a dApp to see.
+    class ProviderRpcError extends Error {
+        constructor(code, message, data) {
+            super(message);
+            this.name = "ProviderRpcError";
+            this.code = code;
+            if (data !== undefined) this.data = data;
+        }
+    }
+
+    // Rebuild a boundary error as the error the page catches, carrying the
+    // code (and data) the extension reported. Without this a dApp cannot tell
+    // a user's refusal (4001) from a wallet that broke, and retries or shows
+    // an error instead of accepting the refusal.
+    //
+    // Whatever code arrived is passed through verbatim rather than being
+    // matched against a list: the extension emits 4001, 4100 and 4902 today,
+    // and a code this file has never heard of is still the truth about what
+    // happened. An error reported with no code at all stays a plain Error —
+    // a ProviderRpcError whose `code` is undefined would advertise a
+    // conformance it does not have. `message` is untouched in every case.
+    function toPageError(error) {
+        const message = (error && error.message) || "Request failed";
+        if (error && error.code !== undefined && error.code !== null) {
+            return new ProviderRpcError(error.code, message, error.data);
+        }
+        return new Error(message);
+    }
+
     // Listen for responses from the content script
     window.addEventListener("message", function onUuid(event) {
         if (event.source !== window) return;
@@ -20,7 +53,7 @@
         if (!p) return;
         delete pending[id];
         if (error) {
-            p.reject(new Error(error.message || "Request failed"));
+            p.reject(toPageError(error));
         } else {
             p.resolve(result);
         }

src/popup/index.js

@@ -9,16 +9,17 @@ const {
     $,
     showView,
     updateDebugBanner,
-    setRenderMain,
+    setBackRenderer,
     pushCurrentView,
     goBack,
     clearViewStack,
 } = require("./views/helpers");
 const { applyTheme } = require("./theme");
-// Views that can be fully re-rendered from persisted state. All others fall
+// Renders a view the popup lands on without having navigated to it forward:
-// back to the nearest restorable parent; see the module for why the
+// on restore here, and on Back. Only the views that can be fully re-rendered
-// secret-bearing views are absent.
+// from persisted state (RESTORABLE_VIEWS, src/popup/restorableViews.js) go
-const { RESTORABLE_VIEWS } = require("./restorableViews");
+// through it; anything else falls back to the nearest restorable parent.
+const { renderView, makeBackRenderer } = require("./viewRouter");
 
 const home = require("./views/home");
 const welcome = require("./views/welcome");
@@ -108,92 +109,23 @@ const ctx = {
     },
 };
 
-function needsAddress(view) {
+// The view modules the router renders through, keyed as it expects them.
-    return (
+const viewModules = {
-        view === "address" ||
+    main: { show: () => fallbackView() },
-        view === "address-token" ||
+    addressDetail,
-        view === "receive" ||
+    addressToken,
-        view === "transaction"
+    receive,
-    );
+    settings,
-}
+    settingsAddToken,
-
+    confirmTx,
-function hasValidAddress() {
+    transactionDetail,
-    return (
+    txStatus,
-        state.selectedWallet !== null &&
+};
-        state.selectedAddress !== null &&
-        state.wallets[state.selectedWallet] &&
-        state.wallets[state.selectedWallet].addresses[state.selectedAddress]
-    );
-}
 
 function restoreView() {
-    const view = state.currentView;
+    if (!renderView(state.currentView, state, viewModules)) {
-    if (!view || !RESTORABLE_VIEWS.has(view)) {
-        return fallbackView();
-    }
-
-    if (needsAddress(view) && !hasValidAddress()) {
-        return fallbackView();
-    }
-
-    if (view === "address-token" && !state.selectedToken) {
-        return fallbackView();
-    }
-
-    switch (view) {
-        case "address":
-            addressDetail.show();
-            break;
-        case "address-token":
-            addressToken.show();
-            break;
-        case "receive":
-            receive.show();
-            break;
-        case "settings":
-            settings.show();
-            break;
-        case "settings-addtoken":
-            settingsAddToken.show();
-            break;
-        case "confirm-tx":
-            if (state.viewData && state.viewData.pendingTx) {
-                confirmTx.restore();
-            } else {
         fallbackView();
     }
-            break;
-        case "transaction":
-            if (state.viewData && state.viewData.tx) {
-                transactionDetail.render();
-            } else {
-                fallbackView();
-            }
-            break;
-        case "wait-tx":
-            // Resumes the receipt poll from the persisted broadcast time.
-            if (!txStatus.restoreWait()) {
-                fallbackView();
-            }
-            break;
-        case "success-tx":
-            if (state.viewData && state.viewData.hash) {
-                txStatus.renderSuccess();
-            } else {
-                fallbackView();
-            }
-            break;
-        case "error-tx":
-            if (state.viewData && state.viewData.message) {
-                txStatus.renderError();
-            } else {
-                fallbackView();
-            }
-            break;
-        default:
-            fallbackView();
-            break;
-    }
 }
 
 function fallbackView() {
@@ -247,7 +179,7 @@ async function init() {
         settings.show();
     });
 
-    setRenderMain(renderWalletList);
+    setBackRenderer(makeBackRenderer(state, viewModules));
 
     welcome.init(ctx);
     addWallet.init(ctx);

src/popup/viewRouter.js

@@ -0,0 +1,167 @@
+// Rendering a view the popup lands on without having navigated to it
+// forward: on restore, and on Back. In both cases the view may never have
+// been rendered in this page load — a reopened popup renders only the
+// wallet list and the view it restores onto, so every other view is still
+// the blank static template from index.html — so unhiding it is not enough.
+//
+// Forward navigation renders as it goes and must NOT come through here:
+// rendering a second time would re-fetch and clobber whatever the view has
+// in flight.
+//
+// The view modules are injected and nothing here touches the DOM, so the
+// dispatch and its data guards can be tested directly; src/popup/index.js
+// cannot be required outside a browser.
+
+const { RESTORABLE_VIEWS } = require("./restorableViews");
+
+// The views this page load has rendered.
+//
+// The Back path cannot otherwise tell its two cases apart. A view the popup
+// never rendered is still the blank template from index.html and has to be
+// rendered; a view already on the page must NOT be rendered again, because
+// a second render re-fetches and overwrites whatever the user has typed
+// into it and not yet saved.
+//
+// Registration is showView() in views/helpers.js, which is the last thing
+// every render path runs — restoreView()'s, the Back path's, and every
+// forward show(). That is the point of putting it there rather than in the
+// individual views: a view added later registers itself with no one having
+// to remember it, so this cannot decay.
+//
+// Module scope is page-load scope: the popup loads this module once per
+// page load, and a reopened popup gets a fresh, empty set — which is
+// exactly the state that makes the Back path render.
+const renderedViews = new Set();
+
+function markViewRendered(view) {
+    if (view) renderedViews.add(view);
+}
+
+// Begin a fresh page-load scope. The popup gets one by being loaded; the
+// unit tests, which simulate several page loads against one module
+// instance, ask for one.
+function resetRenderedViews() {
+    renderedViews.clear();
+}
+
+// Home is the exception: Back re-renders it every time, which is what the
+// popup did before this router existed (index.js registered
+// renderWalletList() as setRenderMain(), and goBack() called it on every
+// Back onto "main"). It must stay that way — the wallet list has to reflect
+// what changed while the user was away from it, such as a wallet renamed or
+// an address removed in Settings — and Home holds no unsaved input to lose.
+const ALWAYS_RENDER_ON_BACK = new Set(["main"]);
+
+// Views that render an address the user picked and cannot be rendered
+// without one.
+const ADDRESS_VIEWS = new Set([
+    "address",
+    "address-token",
+    "receive",
+    "transaction",
+]);
+
+function needsAddress(view) {
+    return ADDRESS_VIEWS.has(view);
+}
+
+function hasValidAddress(state) {
+    return Boolean(
+        state.selectedWallet !== null &&
+        state.selectedAddress !== null &&
+        state.wallets[state.selectedWallet] &&
+        state.wallets[state.selectedWallet].addresses[state.selectedAddress],
+    );
+}
+
+// Render `view` from persisted state. Each view module shows itself, so a
+// true return means the view is both rendered and on screen.
+//
+// Returns false when the view is not one the popup renders from state, or
+// when the state it would render is gone — a token no longer selected, a
+// transaction no longer persisted. The caller falls back rather than
+// putting an empty template on screen.
+function renderView(view, state, views) {
+    if (!view || !RESTORABLE_VIEWS.has(view)) return false;
+    if (needsAddress(view) && !hasValidAddress(state)) return false;
+    if (view === "address-token" && !state.selectedToken) return false;
+
+    const data = state.viewData || {};
+    switch (view) {
+        case "main":
+            views.main.show();
+            return true;
+        case "address":
+            views.addressDetail.show();
+            return true;
+        case "address-token":
+            views.addressToken.show();
+            return true;
+        case "receive":
+            views.receive.show();
+            return true;
+        case "settings":
+            views.settings.show();
+            return true;
+        case "settings-addtoken":
+            views.settingsAddToken.show();
+            return true;
+        case "confirm-tx":
+            if (!data.pendingTx) return false;
+            views.confirmTx.restore();
+            return true;
+        case "transaction":
+            if (!data.tx) return false;
+            views.transactionDetail.render();
+            return true;
+        case "wait-tx":
+            // Resumes the receipt poll from the persisted broadcast time,
+            // and answers false when there is nothing resumable left.
+            return Boolean(views.txStatus.restoreWait());
+        case "success-tx":
+            if (!data.hash) return false;
+            views.txStatus.renderSuccess();
+            return true;
+        case "error-tx":
+            if (!data.message) return false;
+            views.txStatus.renderError();
+            return true;
+        default:
+            return false;
+    }
+}
+
+// The Back-path renderer, registered with setBackRenderer() in
+// views/helpers.js.
+//
+// Returns false — leaving goBack() to unhide the view, as it always did —
+// in the two cases where the view is known to be on the page already:
+//
+//   - It is not one the popup renders from persisted state. The restored
+//     stack is filtered against RESTORABLE_VIEWS, so such a view can only
+//     be on the stack from this page load, where forward navigation
+//     rendered it on the way in.
+//   - This page load has rendered it. Re-rendering would re-fetch and
+//     clobber what it holds; Home is rendered anyway, see above.
+//
+// What is left is the case the router exists for: a view on the stack that
+// this page load has never rendered, whose template is still blank.
+function makeBackRenderer(state, views) {
+    return function renderBack(view) {
+        if (!RESTORABLE_VIEWS.has(view)) return false;
+        if (renderedViews.has(view) && !ALWAYS_RENDER_ON_BACK.has(view)) {
+            return false;
+        }
+        if (!renderView(view, state, views)) {
+            views.main.show();
+        }
+        return true;
+    };
+}
+
+module.exports = {
+    renderView,
+    makeBackRenderer,
+    markViewRendered,
+    resetRenderedViews,
+};

src/popup/views/helpers.js

@@ -7,6 +7,7 @@ const {
     getAddressValueUsd,
 } = require("../../shared/prices");
 const { state, saveState, currentNetwork } = require("../../shared/state");
+const { markViewRendered } = require("../viewRouter");
 
 // When views are added, removed, or transitions between them change,
 // update the view-navigation documentation in README.md to match.
@@ -76,6 +77,10 @@ function showView(name) {
     }
     clearFlash();
     state.currentView = name;
+    // A view's show() ends here, so this is where the Back path learns the
+    // view is no longer the blank template from index.html and must not be
+    // rendered a second time. See viewRouter.js.
+    markViewRendered(name);
     saveState();
     updateDebugBanner(name);
 }
@@ -111,12 +116,19 @@ function updateDebugBanner(viewName) {
     }
 }
 
-// Callback to re-render the main/home view when navigating back to it.
+// Callback that renders a view being navigated BACK onto. Set once by
-// Set once by index.js via setRenderMain().
+// index.js via setBackRenderer(), which routes the view through the same
-let _renderMain = null;
+// per-view render and data guards restoreView() uses.
+//
+// It answers true when it took the navigation — the view is rendered and
+// shown, or its backing data was gone and it fell back — and false for a
+// view the popup does not render from persisted state. Those can only be
+// on the stack from this page load, because the stack is filtered on load,
+// so they have already been rendered and only need unhiding.
+let _renderBack = null;
 
-function setRenderMain(fn) {
+function setBackRenderer(fn) {
-    _renderMain = fn;
+    _renderBack = fn;
 }
 
 // Push the current view onto the navigation stack so goBack() can
@@ -136,9 +148,11 @@ function goBack() {
     } else {
         target = "main";
     }
-    if (target === "main" && _renderMain) {
+    // A popped view is landed on, not navigated to. If the popup has been
-        _renderMain();
+    // closed and reopened since the view was pushed, nothing has ever
-    }
+    // rendered it in this page load and its template is still blank, so it
+    // has to be rendered here rather than merely unhidden.
+    if (_renderBack && _renderBack(target)) return;
     showView(target);
 }
 
@@ -470,7 +484,7 @@ module.exports = {
     showView,
     onViewLeave,
     updateDebugBanner,
-    setRenderMain,
+    setBackRenderer,
     pushCurrentView,
     goBack,
     clearViewStack,

tests/backNavigation.test.js

@@ -0,0 +1,329 @@
+// Back after reopening the popup (#268).
+//
+// A reopened popup renders the wallet list and the one view it restores
+// onto; every other view is still the blank static template from
+// index.html. goBack() used to only unhide its target, so Back landed on
+// that blank template for any view the popup had not rendered in this page
+// load. These tests drive the real goBack() with the real router wired to
+// recording view modules, so what is asserted is which view render ran —
+// the thing that was missing.
+//
+// The rendering itself is asserted against the real popup in a real
+// browser by tests/e2e/run.js; here the DOM is a stub, because goBack()
+// only needs showView() to work.
+
+const els = new Map();
+
+function fakeEl() {
+    return {
+        textContent: "",
+        innerHTML: "",
+        classList: {
+            toggle() {},
+            add() {},
+            remove() {},
+            contains: () => false,
+        },
+        remove() {},
+    };
+}
+
+globalThis.document = {
+    getElementById(id) {
+        if (!els.has(id)) els.set(id, fakeEl());
+        return els.get(id);
+    },
+};
+
+// helpers.js pulls in state.js, which reads chrome.storage.local at load.
+globalThis.chrome = {
+    storage: { local: { get: async () => ({}), set: async () => {} } },
+};
+
+const {
+    showView,
+    goBack,
+    setBackRenderer,
+    pushCurrentView,
+} = require("../src/popup/views/helpers");
+const {
+    makeBackRenderer,
+    markViewRendered,
+    resetRenderedViews,
+} = require("../src/popup/viewRouter");
+const { state } = require("../src/shared/state");
+
+const ADDRESS = "0x1111111111111111111111111111111111111111";
+const TOKEN = "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48";
+
+let calls;
+
+// Stand-ins for the view modules. Each records itself and then shows its
+// view, which is what every real view render ends with — so the assertions
+// can tell "rendered and shown" apart from "merely unhidden".
+function recorder(name, view) {
+    return () => {
+        calls.push(name);
+        showView(view);
+    };
+}
+
+function makeViews() {
+    return {
+        main: { show: recorder("main", "main") },
+        addressDetail: { show: recorder("addressDetail", "address") },
+        addressToken: { show: recorder("addressToken", "address-token") },
+        receive: { show: recorder("receive", "receive") },
+        settings: { show: recorder("settings", "settings") },
+        settingsAddToken: {
+            show: recorder("settingsAddToken", "settings-addtoken"),
+        },
+        confirmTx: { restore: recorder("confirmTx", "confirm-tx") },
+        transactionDetail: {
+            render: recorder("transactionDetail", "transaction"),
+        },
+        txStatus: {
+            restoreWait: () => {
+                calls.push("waitTx");
+                showView("wait-tx");
+                return true;
+            },
+            renderSuccess: recorder("successTx", "success-tx"),
+            renderError: recorder("errorTx", "error-tx"),
+        },
+    };
+}
+
+// The popup as it stands just after a reopen: one wallet with one address,
+// the view the popup restored onto, and the stack behind it.
+//
+// A reopen is a fresh page load, so the record of what has been rendered
+// starts empty — that emptiness is what makes the Back path render at all.
+// Returns the view modules so a test can drive forward navigation through
+// the same recorders the router renders through.
+function reopenedOn(view, stack, extra) {
+    calls = [];
+    resetRenderedViews();
+    state.wallets = [
+        {
+            name: "Wallet 1",
+            addresses: [{ address: ADDRESS, balance: "0", tokenBalances: [] }],
+        },
+    ];
+    state.selectedWallet = 0;
+    state.selectedAddress = 0;
+    state.selectedToken = null;
+    state.viewData = null;
+    state.currentView = view;
+    state.viewStack = stack.slice();
+    Object.assign(state, extra || {});
+    // Restoring onto a view renders it, so the reopened popup has that one
+    // view on the page and nothing else.
+    markViewRendered(view);
+    const views = makeViews();
+    setBackRenderer(makeBackRenderer(state, views));
+    return views;
+}
+
+// The reproduction from the issue, step for step.
+describe("Back onto a view the reopened popup never rendered", () => {
+    test("Back from settings renders the address detail underneath", () => {
+        reopenedOn("settings", ["main", "address"]);
+        goBack();
+        expect(calls).toEqual(["addressDetail"]);
+        expect(state.currentView).toBe("address");
+        expect(state.viewStack).toEqual(["main"]);
+    });
+
+    test("Back onto the token detail renders it", () => {
+        reopenedOn("settings", ["main", "address", "address-token"], {
+            selectedToken: TOKEN,
+        });
+        goBack();
+        expect(calls).toEqual(["addressToken"]);
+        expect(state.currentView).toBe("address-token");
+    });
+
+    test("Back onto Receive renders it", () => {
+        reopenedOn("settings", ["main", "address", "receive"]);
+        goBack();
+        expect(calls).toEqual(["receive"]);
+        expect(state.currentView).toBe("receive");
+    });
+
+    test("Back onto the transaction detail renders it", () => {
+        reopenedOn("settings", ["main", "transaction"], {
+            viewData: { tx: { hash: "0xdead" } },
+        });
+        goBack();
+        expect(calls).toEqual(["transactionDetail"]);
+        expect(state.currentView).toBe("transaction");
+    });
+
+    test("Back onto the transaction confirmation restores it", () => {
+        reopenedOn("settings", ["main", "confirm-tx"], {
+            viewData: { pendingTx: { to: ADDRESS, amount: "1" } },
+        });
+        goBack();
+        expect(calls).toEqual(["confirmTx"]);
+        expect(state.currentView).toBe("confirm-tx");
+    });
+
+    test("Back onto the success screen renders it", () => {
+        reopenedOn("settings", ["main", "success-tx"], {
+            viewData: { hash: "0xdead" },
+        });
+        goBack();
+        expect(calls).toEqual(["successTx"]);
+        expect(state.currentView).toBe("success-tx");
+    });
+
+    test("Back onto the failure screen renders it", () => {
+        reopenedOn("settings", ["main", "error-tx"], {
+            viewData: { message: "execution reverted" },
+        });
+        goBack();
+        expect(calls).toEqual(["errorTx"]);
+        expect(state.currentView).toBe("error-tx");
+    });
+
+    test("Back onto Home renders the wallet list", () => {
+        reopenedOn("settings", ["main"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("Back with an empty stack renders Home", () => {
+        reopenedOn("settings", []);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+});
+
+// The guards are restoreView()'s, so a popped view whose backing data is
+// gone lands on Home rather than on an empty template.
+describe("Back onto a view whose backing data is gone", () => {
+    test("the token detail with no token selected falls back to Home", () => {
+        reopenedOn("settings", ["main", "address-token"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("the transaction detail with no transaction falls back to Home", () => {
+        reopenedOn("settings", ["main", "transaction"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("the confirmation with no pending transaction falls back to Home", () => {
+        reopenedOn("settings", ["main", "confirm-tx"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("an address view with no address selected falls back to Home", () => {
+        reopenedOn("settings", ["main", "receive"], {
+            selectedAddress: null,
+        });
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("the success screen with no transaction hash falls back to Home", () => {
+        reopenedOn("settings", ["main", "success-tx"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("the failure screen with no message falls back to Home", () => {
+        reopenedOn("settings", ["main", "error-tx"]);
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+
+    test("a wait that can no longer be resumed falls back to Home", () => {
+        reopenedOn("settings", ["main", "wait-tx"]);
+        const views = makeViews();
+        views.txStatus.restoreWait = () => false;
+        setBackRenderer(makeBackRenderer(state, views));
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+});
+
+// Forward navigation renders as it goes, and a second render would re-fetch
+// and clobber whatever the view holds — an unsaved edit, a request in
+// flight. So the Back path renders only a view this page load has never
+// rendered, and merely unhides every other one: the views it does not
+// render from persisted state, and the views already on the page.
+describe("what the Back path leaves alone", () => {
+    test("forward navigation renders nothing by itself", () => {
+        reopenedOn("address", ["main"]);
+        pushCurrentView();
+        showView("send");
+        expect(calls).toEqual([]);
+        expect(state.viewStack).toEqual(["main", "address"]);
+    });
+
+    test("Back onto a live-session view only unhides it", () => {
+        reopenedOn("confirm-tx", ["main", "address", "send"]);
+        goBack();
+        expect(calls).toEqual([]);
+        expect(state.currentView).toBe("send");
+    });
+
+    test("Back renders its target exactly once", () => {
+        reopenedOn("settings", ["main", "address"]);
+        goBack();
+        expect(calls.filter((c) => c === "addressDetail")).toHaveLength(1);
+    });
+
+    test("Back onto a view this page load already rendered only unhides it", () => {
+        const views = reopenedOn("main", []);
+        pushCurrentView();
+        views.addressDetail.show();
+        pushCurrentView();
+        views.settings.show();
+        calls = [];
+        goBack();
+        expect(calls).toEqual([]);
+        expect(state.currentView).toBe("address");
+    });
+
+    // The unit mirror of the regression the browser suite pins: Settings
+    // reassigns its fields from persisted state on every render, so a
+    // re-render on the way back discards an edit the user has not saved.
+    test("Back onto Settings visited earlier in this page load does not re-render it", () => {
+        const views = reopenedOn("main", []);
+        pushCurrentView();
+        views.settings.show();
+        pushCurrentView();
+        views.settingsAddToken.show();
+        calls = [];
+        goBack();
+        expect(calls).toEqual([]);
+        expect(state.currentView).toBe("settings");
+    });
+
+    // Home is the deliberate exception, unchanged from the popup's
+    // behaviour before the router existed: it re-renders on every Back so
+    // the wallet list reflects what changed while the user was away.
+    test("Back onto Home renders it again even when it is already on the page", () => {
+        const views = reopenedOn("main", []);
+        pushCurrentView();
+        views.addressDetail.show();
+        calls = [];
+        goBack();
+        expect(calls).toEqual(["main"]);
+        expect(state.currentView).toBe("main");
+    });
+});

tests/e2e/Dockerfile

@@ -0,0 +1,34 @@
+# Chrome end-to-end image: the pinned Playwright image with this repo and a
+# freshly built extension inside it, built by script/test-e2e. The suite is
+# still started with `docker run`, so every runtime flag the harness needs
+# (--ipc=host in particular) applies as before.
+#
+# The repo is baked in rather than bind-mounted because a bind mount does
+# not resolve under Gitea Actions: the runner runs the job in a container
+# against the HOST's docker socket, so the source side of a -v is resolved
+# by the host daemon while the job's checkout lives on a docker volume that
+# is not a host path -- the mount silently succeeds and /work is empty. A
+# build context is streamed to the daemon and so works from anywhere.
+# Building the extension here too means the machine starting a run needs
+# docker and nothing else.
+
+# mcr.microsoft.com/playwright:v1.56.0-noble, 2026-08-09
+#
+# The playwright-core devDependency is pinned to the matching Playwright
+# version (1.56.0) and the two must be bumped together: the browsers ship
+# inside this image, and playwright-core looks for the exact browser
+# revision its own version expects. A mismatch fails at launch.
+FROM mcr.microsoft.com/playwright@sha256:35246d87a7c88ea9b771c65d33171b2611b02a8253b4b12ce6f94376c55f99f2
+
+WORKDIR /work
+
+# Same layering as the root Dockerfile: script/bootstrap installs the
+# prerequisites and the dependencies, and the manifests are copied first so
+# that layer is cached until they change.
+COPY script/ script/
+COPY package.json yarn.lock ./
+RUN script/bootstrap
+
+COPY . .
+
+RUN make build

tests/e2e/firefox/Dockerfile

@@ -1,10 +1,24 @@
 # Firefox end-to-end image: stock Firefox plus geckodriver on a node base,
-# built by script/test-e2e-firefox. The repo is bind-mounted at /work; the
+# with this repo and a freshly built extension inside it, built by
-# harness itself has no dependencies, so nothing is installed for it.
+# script/test-e2e-firefox. The harness itself has no dependencies, so
+# nothing is installed for it.
 #
-# All three external artifacts are pinned by digest. The Firefox version in
+# The build context is the repo root. The repo is baked in rather than
-# particular must not float: -remote-allow-system-access is mandatory on 153
+# bind-mounted because a bind mount does not resolve under Gitea Actions:
-# and was not on 142, so the flag the harness passes is version-coupled.
+# the runner runs the job in a container against the HOST's docker socket,
+# so the source side of a -v is resolved by the host daemon while the job's
+# checkout lives on a docker volume that is not a host path -- the mount
+# silently succeeds and /work is empty. Baking the build in is also the
+# only way this suite can have both a built extension and the
+# `--network none` it runs under, since a container with no network cannot
+# install anything.
+#
+# All three external artifacts are pinned by digest, and are fetched in
+# layers above the repo copy, so editing the harness or any source file
+# re-runs only the two cheap layers at the bottom. The Firefox version in
+# particular must not float: -remote-allow-system-access is mandatory on
+# 153 and was not on 142, so the flag the harness passes is
+# version-coupled.
 
 # node:22-bookworm-slim, 2026-08-12
 FROM node@sha256:d649c27dae7ba0137b3cef5dd75baa422c08dc3d9e3fc0c23dfb172dc3cc6436
@@ -48,4 +62,16 @@ ENV FIREFOX_BIN=/opt/firefox/firefox
 ENV GECKODRIVER=/usr/local/bin/geckodriver
 
 WORKDIR /work
+
+# Same layering as the root Dockerfile: script/bootstrap installs the
+# prerequisites and the dependencies, and the manifests are copied first so
+# that layer is cached until they change.
+COPY script/ script/
+COPY package.json yarn.lock ./
+RUN script/bootstrap
+
+COPY . .
+
+RUN make build
+
 CMD ["node", "tests/e2e/firefox/run.js", "dist/firefox"]

tests/e2e/network.js

@@ -86,9 +86,11 @@ const DAPP_URL = DAPP_ORIGIN + "/";
 // never drive the popup that has to settle it; start() files the promise
 // under a key and settle() collects it once the prompt has been dealt with.
 //
-// The rejection branch records `code` as it arrives. EIP-1193 says a user
+// The rejection branch records the whole observable shape of the error as it
-// rejection is a ProviderRpcError carrying code 4001; what the page can
+// arrives — name, message, and whether a `code` is present at all as distinct
-// actually see is recorded here rather than assumed, and asserted in run.js.
+// from its value. EIP-1193 says a user rejection is a ProviderRpcError
+// carrying code 4001; what the page can actually see is recorded here rather
+// than assumed, and asserted in run.js.
 //
 // The message log is the page's half of the boundary observation: every
 // AUTISTMASK_* message that crosses between this page and the content
@@ -120,6 +122,7 @@ const DAPP_HTML = [
     "                    return {",
     "                        settled: 'rejected',",
     "                        message: String((error && error.message) || error),",
+    "                        name: error ? error.name : undefined,",
     "                        hasCode: !!error && 'code' in Object(error),",
     "                        code: error ? error.code : undefined,",
     "                    };",

tests/e2e/run.js

@@ -419,6 +419,172 @@ test("reopening the popup never lands on the phrase screen (#161)", async (env)
     assertWiped(st, env.phrase, "after reopening the popup");
 });
 
+// ------------------------------- Back after reopening the popup (#268)
+
+// A reopened popup renders the wallet list and the view it restores onto,
+// and nothing else: every other screen is still the blank static template
+// from index.html. Back used to only unhide its target, which is why these
+// have to run against the real popup — the template is present and
+// well-formed, so only its emptiness distinguishes the defect, and only a
+// real reopen produces it.
+
+// Everything the address screen must have on it, read out of the DOM.
+function addressScreenState(page) {
+    return page.evaluate(() => {
+        const line = document.getElementById("address-line");
+        const balances = document.getElementById("address-balances");
+        return {
+            hidden: document
+                .getElementById("view-address")
+                .classList.contains("hidden"),
+            line: line ? line.innerText.trim() : "",
+            balances: balances ? balances.innerText.trim() : "",
+        };
+    });
+}
+
+// Close and reopen the page rather than reload it: that is what the toolbar
+// popup does, and it is the only thing that produces the unrendered views.
+async function reopenPopup(env, restoredView) {
+    await env.page.close();
+    env.page = await openPopup(env.ctx, env.popupUrl);
+    await visible(env.page, restoredView);
+}
+
+// The reproduction from the issue, step for step.
+test("Back after reopening the popup renders the address screen (#268)", async (env) => {
+    await openAddressDetail(env.page);
+    const before = await addressScreenState(env.page);
+    assert(
+        before.line.length > 0,
+        "the address screen was blank to begin with",
+    );
+
+    await env.page.click("#btn-settings");
+    await visible(env.page, "#view-settings");
+
+    await reopenPopup(env, "#view-settings");
+
+    await env.page.click("#btn-settings-back");
+    await visible(env.page, "#view-address");
+
+    const after = await addressScreenState(env.page);
+    assert(
+        after.line === before.line,
+        "the address line reads " +
+            JSON.stringify(after.line) +
+            ", expected " +
+            JSON.stringify(before.line),
+    );
+    assert(
+        after.balances.includes("ETH"),
+        "the balances read " + JSON.stringify(after.balances),
+    );
+});
+
+// The same defect one screen further in. Receive holds the address twice
+// over — as text and as the QR code the sender scans — and a blank one is
+// worse than a missing screen.
+// Everything the Receive screen must have on it. The QR code is read as
+// pixels, not as an element: the blank template carries the canvas too, a
+// default 300x150 one with nothing drawn on it and every pixel fully
+// transparent. A drawn QR paints an opaque background across the whole
+// canvas, so a single opaque pixel is the whole question.
+function receiveScreenState(page) {
+    return page.evaluate(() => {
+        const block = document.getElementById("receive-address-block");
+        const canvas = document.getElementById("receive-qr");
+        const px = canvas
+            .getContext("2d")
+            .getImageData(0, 0, canvas.width, canvas.height).data;
+        let opaque = 0;
+        for (let i = 3; i < px.length; i += 4) {
+            if (px[i] > 0) opaque += 1;
+        }
+        return {
+            address: block.dataset.full || "",
+            text: block.innerText.trim(),
+            qrOpaquePixels: opaque,
+        };
+    });
+}
+
+test("Back after reopening the popup renders the Receive screen (#268)", async (env) => {
+    await openAddressDetail(env.page);
+    await env.page.click("#btn-receive");
+    await visible(env.page, "#view-receive");
+    const before = await receiveScreenState(env.page);
+    assert(
+        /^0x[0-9a-fA-F]{40}$/.test(before.address),
+        "Receive showed no address to begin with: " +
+            JSON.stringify(before.address),
+    );
+
+    await env.page.click("#btn-settings");
+    await visible(env.page, "#view-settings");
+
+    await reopenPopup(env, "#view-settings");
+
+    await env.page.click("#btn-settings-back");
+    await visible(env.page, "#view-receive");
+
+    const shown = await receiveScreenState(env.page);
+    assert(
+        shown.address === before.address,
+        "Receive shows " +
+            JSON.stringify(shown.address) +
+            ", expected " +
+            JSON.stringify(before.address),
+    );
+    assert(
+        shown.text.includes(before.address),
+        "the Receive address is not on screen: " + JSON.stringify(shown.text),
+    );
+    assert(shown.qrOpaquePixels > 0, "Receive shows an unpainted QR code");
+
+    // Leave the suite where it found it.
+    await env.page.click("#btn-receive-back");
+    await visible(env.page, "#view-address");
+    await env.page.click("#btn-address-back");
+    await visible(env.page, "#view-main");
+});
+
+// The other half of the requirement: Back renders a screen this page load
+// never rendered, and must NOT re-render one it already has on screen.
+// settings.show() reassigns #settings-rpc from persisted state, so
+// re-rendering Settings on the way back would silently revert whatever the
+// user typed and had not saved yet — and they could then press Save and
+// store the value they believed they had replaced. No reopen here: this is
+// an ordinary in-session forward-and-back, which is exactly why the render
+// must not happen.
+test("Back onto Settings keeps unsaved input (#268)", async (env) => {
+    await visible(env.page, "#view-main");
+    await env.page.click("#btn-settings");
+    await visible(env.page, "#view-settings");
+
+    const typed = "https://rpc.example.invalid/unsaved";
+    await env.page.fill("#settings-rpc", typed);
+
+    await env.page.click("#btn-settings-add-token");
+    await visible(env.page, "#view-settings-addtoken");
+    await env.page.click("#btn-settings-addtoken-back");
+    await visible(env.page, "#view-settings");
+
+    const kept = await env.page.inputValue("#settings-rpc");
+    assert(
+        kept === typed,
+        "the unsaved RPC URL reads " +
+            JSON.stringify(kept) +
+            ", expected " +
+            JSON.stringify(typed),
+    );
+
+    // Leave the suite where it found it. The typed value was never saved,
+    // and Settings reloads the field from state next time it renders.
+    await env.page.click("#btn-settings-back");
+    await visible(env.page, "#view-main");
+});
+
 // -------------------------------------------- address removal (#162)
 
 // Number of address rows across every wallet in the list, counted in the DOM
@@ -1591,15 +1757,14 @@ async function lastResponseError(page) {
 }
 
 // A rejected prompt, asserted at both ends: the page's promise rejected
-// rather than hanging or resolving, and the response that crossed the
+// rather than hanging or resolving, and EIP-1193 code 4001 is present both
-// boundary carried EIP-1193 code 4001.
+// on the wire and on the Error the calling page catches.
 //
-// The code is asserted on the wire because that is the only place it
+// Both ends matter because they used to disagree. The code crossed the
-// survives. src/content/inpage.js rebuilds the rejection as `new
+// boundary correctly and src/content/inpage.js then threw it away, rebuilding
-// Error(error.message)`, so the Error the calling page catches carries the
+// every rejection as `new Error(error.message)` — so a dApp branching on
-// message and no code. That is reported rather than asserted either way —
+// `err.code === 4001` saw undefined and could not tell a refusal from a
-// locking in the current behaviour would make the gap permanent, and
+// failure (#274). Asserting only the wire would leave that gap invisible.
-// asserting the code on the Error would fail today.
 async function assertUserRejection(page, key, label) {
     const outcome = await settleRequest(page, key);
     assert(
@@ -1621,15 +1786,32 @@ async function assertUserRejection(page, key, label) {
             " did not carry EIP-1193 code 4001 across the boundary: " +
             JSON.stringify(error),
     );
+    assert(
+        outcome.hasCode,
+        label +
+            " reached the page as an error with no code property at all, so a " +
+            "dApp cannot tell the user's refusal from a failure: " +
+            JSON.stringify(outcome),
+    );
+    assert(
+        outcome.code === 4001,
+        label +
+            " reached the page with code " +
+            JSON.stringify(outcome.code) +
+            " rather than EIP-1193 4001",
+    );
+    assert(
+        outcome.name === "ProviderRpcError",
+        label +
+            " reached the page as " +
+            JSON.stringify(outcome.name) +
+            " rather than an EIP-1193 ProviderRpcError",
+    );
     console.log(
         "# " +
             label +
-            ": boundary code=" +
+            ": code 4001 on the wire and on the page's " +
-            error.code +
+            outcome.name,
-            " page Error.code=" +
-            JSON.stringify(outcome.code) +
-            " page Error carries a code=" +
-            outcome.hasCode,
     );
     return outcome;
 }

tests/inpageErrors.test.js

@@ -0,0 +1,310 @@
+// The EIP-1193 error the page actually catches (src/content/inpage.js).
+//
+// The bug this pins down (issue #274): the provider rebuilt every failure as
+// `new Error(error.message)`, so the `code` the background produced and the
+// content script relayed intact was thrown away in the last hop. A dApp
+// checking `err.code === 4001` — the standard way to tell "the user said no"
+// from "the wallet broke" — saw undefined, and well-behaved sites showed an
+// error or retried instead of accepting the refusal.
+//
+// inpage.js is a bare IIFE injected into the page's JS context, not a module:
+// it takes no import and exports nothing, and reaches for `window` at load.
+// So it is evaluated here the way the browser evaluates it, against a stub
+// window, and the provider is collected from `window.ethereum`. The globals it
+// touches are passed in as function parameters rather than assigned to
+// globalThis: nothing leaks between tests, and the source is compiled in this
+// realm, so the errors it constructs are comparable against this file's own
+// `Error` — which a second realm's intrinsics would silently defeat.
+//
+// There is no jsdom in this repo; see tests/txStatus.test.js.
+
+const fs = require("fs");
+const path = require("path");
+const { webcrypto } = require("crypto");
+
+const SOURCE = fs.readFileSync(
+    path.join(__dirname, "..", "src", "content", "inpage.js"),
+    "utf8",
+);
+
+const loadInto = new Function(
+    "window",
+    "self",
+    "crypto",
+    "Event",
+    "CustomEvent",
+    SOURCE,
+);
+
+class StubEvent {
+    constructor(type) {
+        this.type = type;
+    }
+}
+
+class StubCustomEvent extends StubEvent {
+    constructor(type, init) {
+        super(type);
+        this.detail = init && init.detail;
+    }
+}
+
+// Every code the background emits on the RPC path today, read out of
+// src/background/index.js. The provider must not know this list — it passes
+// through whatever arrived — but the cases below are the real ones.
+const REJECTED = 4001; // user rejected the request
+const UNAUTHORIZED = 4100; // site not connected / wrong address
+const UNRECOGNIZED_CHAIN = 4902; // switch/add to an unsupported chain
+
+// A stub window with the four things inpage.js touches: message listeners,
+// postMessage out to the content script, window.ethereum, and dispatchEvent
+// for the EIP-6963 announcement.
+function loadProvider() {
+    const messageListeners = [];
+    const posted = [];
+
+    const win = {
+        addEventListener(type, fn) {
+            if (type === "message") messageListeners.push(fn);
+        },
+        removeEventListener(type, fn) {
+            const i = messageListeners.indexOf(fn);
+            if (type === "message" && i !== -1) messageListeners.splice(i, 1);
+        },
+        postMessage(data) {
+            posted.push(data);
+        },
+        dispatchEvent() {
+            return true;
+        },
+    };
+    win.window = win;
+
+    loadInto(win, win, webcrypto, StubEvent, StubCustomEvent);
+
+    // Deliver the content script's answer to an outstanding request. The id is
+    // read back off the wire rather than assumed: inpage.js issues its own
+    // eth_chainId at load, so the first id a test sees is not 1.
+    function respond(response) {
+        const request = posted
+            .filter((m) => m.type === "AUTISTMASK_REQUEST")
+            .pop();
+        expect(request).toBeDefined();
+        const event = {
+            source: win,
+            data: { type: "AUTISTMASK_RESPONSE", id: request.id, ...response },
+        };
+        for (const fn of messageListeners.slice()) fn(event);
+    }
+
+    return { provider: win.ethereum, posted, respond };
+}
+
+// Start a request, answer it with `response`, and hand back the rejection.
+// Fails the test if the call resolves instead.
+async function rejectionFrom(start, response) {
+    const { provider, respond } = loadProvider();
+    const settled = start(provider).then(
+        (result) => ({ resolved: result }),
+        (error) => ({ error }),
+    );
+    // The provider posts synchronously, so the request is already on the wire.
+    respond(response);
+    const outcome = await settled;
+    expect(outcome).not.toHaveProperty("resolved");
+    return outcome.error;
+}
+
+describe("an EIP-1193 code reaches the page", () => {
+    test("a user rejection arrives as code 4001", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_requestAccounts" }),
+            {
+                error: {
+                    code: REJECTED,
+                    message: "User rejected the request.",
+                },
+            },
+        );
+        expect(err.code).toBe(REJECTED);
+        expect(err.message).toBe("User rejected the request.");
+    });
+
+    test("it is a ProviderRpcError, and an Error", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_requestAccounts" }),
+            {
+                error: {
+                    code: REJECTED,
+                    message: "User rejected the request.",
+                },
+            },
+        );
+        expect(err).toBeInstanceOf(Error);
+        expect(err.name).toBe("ProviderRpcError");
+    });
+
+    test("4100 unauthorized arrives intact", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "personal_sign", params: ["0x00"] }),
+            { error: { code: UNAUTHORIZED, message: "Unauthorized" } },
+        );
+        expect(err.code).toBe(UNAUTHORIZED);
+        expect(err.message).toBe("Unauthorized");
+    });
+
+    test("4902 unrecognized chain arrives intact", async () => {
+        const message =
+            "AutistMask supports Ethereum Mainnet and Sepolia Testnet only.";
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "wallet_switchEthereumChain" }),
+            { error: { code: UNRECOGNIZED_CHAIN, message } },
+        );
+        expect(err.code).toBe(UNRECOGNIZED_CHAIN);
+        expect(err.message).toBe(message);
+    });
+
+    // The provider is not allowed to know the list above: a code added to the
+    // background later must reach the page without this file being edited.
+    test("a code the provider has never heard of is passed through", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_accounts" }),
+            { error: { code: 4900, message: "Disconnected" } },
+        );
+        expect(err.code).toBe(4900);
+    });
+
+    test("data is carried when the boundary sent it", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_call" }),
+            {
+                error: {
+                    code: -32000,
+                    message: "execution reverted",
+                    data: "0x08c379a0",
+                },
+            },
+        );
+        expect(err.code).toBe(-32000);
+        expect(err.data).toBe("0x08c379a0");
+    });
+
+    test("no data property is invented when the boundary sent none", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_requestAccounts" }),
+            {
+                error: {
+                    code: REJECTED,
+                    message: "User rejected the request.",
+                },
+            },
+        );
+        expect("data" in err).toBe(false);
+    });
+});
+
+describe("the message is untouched", () => {
+    test("a coded error keeps the message byte for byte", async () => {
+        const message =
+            "This site asked to sign as an address that is not " +
+            "the active one.";
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "personal_sign" }),
+            { error: { code: UNAUTHORIZED, message } },
+        );
+        expect(err.message).toBe(message);
+    });
+
+    test("an error the background sent with no code keeps its message", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_sendTransaction" }),
+            { error: { message: "No accounts available" } },
+        );
+        expect(err.message).toBe("No accounts available");
+    });
+
+    // A ProviderRpcError whose code is undefined would claim a conformance it
+    // does not have, and `'code' in err` is exactly what a careful dApp asks.
+    test("an error with no code gets no code property at all", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_sendTransaction" }),
+            { error: { message: "No accounts available" } },
+        );
+        expect(err).toBeInstanceOf(Error);
+        expect("code" in err).toBe(false);
+    });
+
+    test("an error with no message keeps the generic fallback", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_sendTransaction" }),
+            { error: { code: REJECTED } },
+        );
+        expect(err.message).toBe("Request failed");
+        expect(err.code).toBe(REJECTED);
+    });
+});
+
+// Every entry point the provider exposes, not just eth_requestAccounts. They
+// all funnel through the same response listener, and this is what says so.
+describe("every request path carries the code", () => {
+    const rejection = {
+        error: { code: REJECTED, message: "User rejected the request." },
+    };
+
+    test("request()", async () => {
+        const err = await rejectionFrom(
+            (p) => p.request({ method: "eth_requestAccounts" }),
+            rejection,
+        );
+        expect(err.code).toBe(REJECTED);
+    });
+
+    test("enable()", async () => {
+        const err = await rejectionFrom((p) => p.enable(), rejection);
+        expect(err.code).toBe(REJECTED);
+    });
+
+    test("send(method, params)", async () => {
+        const err = await rejectionFrom(
+            (p) => p.send("eth_requestAccounts", []),
+            rejection,
+        );
+        expect(err.code).toBe(REJECTED);
+    });
+
+    test("send({ method, params })", async () => {
+        const err = await rejectionFrom(
+            (p) => p.send({ method: "personal_sign", params: ["0x00"] }),
+            rejection,
+        );
+        expect(err.code).toBe(REJECTED);
+    });
+
+    test("sendAsync() hands the code to its callback", async () => {
+        const { provider, respond } = loadProvider();
+        const called = new Promise((resolve) => {
+            provider.sendAsync({ id: 1, method: "eth_requestAccounts" }, (e) =>
+                resolve(e),
+            );
+        });
+        respond(rejection);
+        const err = await called;
+        expect(err.name).toBe("ProviderRpcError");
+        expect(err.code).toBe(REJECTED);
+        expect(err.message).toBe("User rejected the request.");
+    });
+});
+
+describe("the success path is unchanged", () => {
+    test("a result still resolves", async () => {
+        const { provider, respond } = loadProvider();
+        const settled = provider.request({ method: "eth_requestAccounts" });
+        respond({ result: ["0xb61264DEFB0c4B8afb3D73724be15310036743a5"] });
+        await expect(settled).resolves.toEqual([
+            "0xb61264DEFB0c4B8afb3D73724be15310036743a5",
+        ]);
+        expect(provider.selectedAddress).toBe(
+            "0xb61264DEFB0c4B8afb3D73724be15310036743a5",
+        );
+    });
+});