diff options
Diffstat (limited to 'CLAUDE.md')
| -rw-r--r-- | CLAUDE.md | 32 |
1 files changed, 20 insertions, 12 deletions
@@ -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/<hash>/` 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 — |