From 6770ed9cd36fe68610b74826520f8c6effc121f6 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sat, 19 Sep 2026 18:55:53 +0200 Subject: test(hub): the Firefox probe stops opening the developer's own profile MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `test_sticky_header.py[firefox]` failed with twelve setup errors whenever a Firefox was open, and the note in CLAUDE.md said to close it and trust the Chrome half meanwhile. The cause was not snap's single instance: the harness pointed HOME at a throwaway directory, snapd sets its own HOME inside the sandbox, and that directory came back empty on every run — so Firefox opened the real profile, which the open browser locks. `--profile` needs a path the sandbox can see: the snap has a private /tmp, and its home interface grants no hidden directory. Both refusals print "Firefox is already running", which it also prints when nothing is. 24 passed in 15s with a Firefox open throughout, against 12 errors in 60s. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index a7ecbca..f0f90d5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -163,18 +163,26 @@ These are about working on the tree rather than about the design: - **The SPA served in production may be older than this tree.** Check the served `/a//` against `meshbay_hub.api.webapp.ASSET_V` before concluding a fix is missing. `site/` and the Caddy config have never been deployed -- **`test_sticky_header.py[firefox]` needs no Firefox instance on the machine, - and says nothing about the code when one is there.** The harness launches - `firefox --headless --screenshot` with `HOME` pointed at a throwaway - directory, which isolates the *profile* and not snap's single instance: with - any Firefox already up it prints "Firefox is already running, but is not - responding", never loads the page, and the fixture times out at 60 s — eleven - errors at setup that look like a regression and are not. Neither - `--no-remote` nor `--new-instance` changes it; a failed run also appears to - leave a process behind, which blocks the next one. Before reading anything - into these: `ps -eo pid,etimes,args | grep firefox`, and re-run against a - stashed tree. The `[chrome]` half of the same file covers the same geometry - and is the one to trust meanwhile +- **A sandbox can refuse a path without saying so, and the browser blames + something else.** `test_sticky_header.py[firefox]` failed with twelve setup + errors whenever the developer's own Firefox was open, and the note that used + to be here said to close it and trust the `[chrome]` half meanwhile. The + cause was not snap's single instance. The harness pointed `HOME` at a + throwaway directory to isolate the profile; snapd sets its own `HOME` inside + the sandbox, so that directory came back **empty on every run** — the tell, + and it was there all along — and Firefox opened the developer's real profile, + which their browser had locked. `--profile` did not help either, for two more + sandbox rules: the snap has a private `/tmp`, so a directory made there is + not the one it sees ("Could not find profile folder"), and its `home` + interface grants no *hidden* directory, so `~/.cache` is refused too. Both + refusals surface as **"Firefox is already running, but is not responding" — + which it also prints when nothing is running at all**, so the message names + neither the real cause nor even the right question. A plain directory under + `$HOME` (the probe prefers `~/snap/firefox/common`) fixes it: 24 passed in + 15 s with a Firefox open throughout, against 12 errors in 60 s before. The + rule worth keeping: **when a sandboxed program cannot see a path, find out + what it can see before believing what it says** — and an isolation directory + that stays empty is not isolating anything - **One UI source.** `packages/meshbay-hub/src/meshbay_hub/static/` is the interface, for the web and the app alike; `packages/meshbay-client/scripts/ sync-ui.js` copies it (`npm run sync-ui`) and CI fails if the copy drifts — -- cgit v1.2.3