Closes#1108
## What
When an operator selects a region on the Live map, default to **hiding**
nodes outside that region. The operator picked the region for a reason —
far-away markers are visual noise. Operators who want the legacy
show-everything behavior can flip the new **Show all nodes** checkbox
next to the region dropdown.
Default: **off (hide non-region nodes)**. State persists in
`localStorage['mc-region-show-all-nodes']`.
## Why
Tracks the request in #1108 — region filtering currently scopes packet
feeds + metrics but the map keeps every node visible, which defeats the
point of selecting a region in the first place.
## How
- `public/region-filter.js`: new `RegionShowAll` module (`get` / `set` /
`onChange` / `STORAGE_KEY`) plus `RegionFilter.nodesRegionQueryString()`
— returns `®ion=…` only when a region is selected **and** showAll is
off. Other surfaces (packets, metrics) continue to use the unconditional
`regionQueryString()`.
- `public/live.js`: `loadNodes()` appends `nodesRegionQueryString()`;
region-change and showAll-change handlers reload nodes so markers update
immediately.
- `public/live.css`: aligns the new toggle with the existing
`.live-toggles` rhythm.
- `test-1108-region-hide-nodes.js`: 7 unit assertions covering
default-off, persistence across reloads, set/get, and the conditional
query-string builder.
## TDD trail
- `dbf6d6db` — red test commit (assertion failures, helpers do not exist
yet)
- `eefa1185` — green commit (helpers + wiring)
## CDP validation (staging, after hot-deploy)
| state | markers |
| --- | --- |
| no region | 517 |
| region=SJC, showAll=off | **497** (region-scoped) |
| region=SJC, showAll=on | 517 (legacy behavior) |
Toggle state survives reload (`RegionShowAll.get() === true` after
refresh).
## Out of scope
- Static `/map` page (`public/map.js`) — its region UI is jump-buttons,
not the shared `RegionFilter` selector. A follow-up could wire
`nodesRegionQueryString` there too, but it's a separate UX surface.
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
Closes#1369.
## What
Cross-domain embed support, shipped as two halves:
### Part A — CORS env override + read-only contract
* `applyCORSEnv()` reads `CORS_ALLOWED_ORIGINS` (comma-separated,
trimmed, empties dropped). Set in env → overrides
`cfg.CORSAllowedOrigins`. Unset/empty → config.json value wins.
* `Access-Control-Allow-Methods` tightened from `GET, POST, OPTIONS` →
`GET, HEAD, OPTIONS`. The cross-domain surface is read-only by contract;
same-origin admin writes don't go through preflight and are unaffected.
* `config.example.json` adds `corsAllowedOrigins: []` + a comment
explaining the env override and the embed URL pattern.
* No wildcards introduced (still supported as `["*"]` for ops that opt
in). No credentialed CORS.
### Part B — `?embed=1` chrome suppression
* `shouldEmbedRoute(basePage, hashSearch)` — pure helper, allowlisted to
`map` and `channels`, requires `embed=1` in the hash querystring.
* `navigate()` toggles `body.embed` based on the helper.
* CSS hides `.top-nav`, `[data-bottom-nav]`, `.nav-drawer`,
`.nav-drawer-backdrop`, zeroes body padding/margin, reclaims `100dvh`
for `#app.app-fixed`.
Use: `<iframe src="https://analyzer.example/#/map?embed=1">`. For
iframe-only display, no CORS entry is needed (the iframe loads the
document, not a JSON API). The CORS allowlist only matters when the
embedding origin's own JS calls `/api/*` directly.
## Tests
| File | Asserts | Status |
|---|---|---|
| `cmd/server/cors_embed_1369_test.go` | 4 (env override, env-empty,
env-trim, GET/HEAD contract, preflight POST rejected) | green |
| `test-embed-mode-1369.js` | 9 (helper allowlist + param parsing) |
green |
| `cmd/server/cors_test.go` | existing | updated to read-only method-set
assertion |
TDD: 2 red commits (one per part, both compile, both fail on assertions)
→ 2 green commits.
## Out of scope (per the issue's narrow ask)
* Other SPA routes do not honor `?embed=1` (their chrome makes layout
assumptions; defer until requested).
* No iframe sandboxing recommendation — that's the embedder's
responsibility.
* No CSP / `X-Frame-Options` change in this PR — frames are already
permitted; add an explicit `frame-ancestors` policy in a follow-up if
operators want to whitelist embedders at the HTTP layer too.
## Security notes (DJB lens)
* Allowlist is exact-match, case-sensitive string compare — no
normalization, no scheme/host parsing, no surprises.
* No `Access-Control-Allow-Credentials` (would let third parties read
auth'd state via cookies).
* No reflection of arbitrary origins (every echoed origin came from the
allowlist).
* Methods narrowed to read-only; even a misconfigured allowlist can't
grant cross-origin writes through this middleware.
🤖 Generated with OpenClaw
---------
Co-authored-by: bot <bot@corescope.local>
Depending on your Playwright configuration, it will either throw a hard error for duplicate test titles or silently burn CI time running the exact same assertions six times. My apologies.
Added a function to wake the canvas engine if animations are active and not paused. Updated animation rendering logic to handle paused state and reset lastTick for animations.
Added animation control logic to manage active animations and prevent unnecessary rendering. Adjusted canvas properties for better performance and responsiveness.
Instead of forcing Leaflet to recalculate and paint heavy SVG DOM nodes 60 times a second for every moving packet, we will draw the flying dots and lines directly onto a hardware-accelerated HTML5 <canvas> overlaid on the map. Once the animation finishes, it will drop a static Leaflet line to handle the fading tail effect.
## Summary
The channels-ws-batch E2E tests had a race condition causing flaky
failures on CI, blocking PRs #1490, #1500, #1501.
**Root cause:** Tests waited on `messages.length === prev + 1`, but live
WS traffic from the ingestor could bump `length` independently, causing
timeouts. The earlier #1499 fix attempted to find messages by
`m.hash`/`m.id`, but `processWSBatch` stores `packetHash`/`packetId` on
message objects — so the find never matched.
**Fix:** Replace all length-based waiters with `messages.some(m =>
m.packetHash === '<known-hash>')` which is deterministic regardless of
concurrent WS traffic. Also un-skips the explicit-sender test that was
force-skipped in #1502.
## Tests affected
- "processWSBatch with explicit sender appends to messages" —
un-skipped, now passes
- "GRP_TXT shape with 'Sender: text' parses sender from text" —
race-proof
- "dedup by packetHash" — race-proof
- "new WS message while scrolled up" — race-proof
All 6 tests pass locally (6 passed, 0 failed).
Fixes#1498.
---------
Co-authored-by: mc-bot <bot@meshcore.local>
# fix(1506): restore marker-stroke server defaults to v3.7.2 visual
Closes#1506. Refs #1494, #1488.
## Why
PR #1494 introduced operator-tunable marker stroke via
`--mc-marker-stroke-*` CSS vars but chose new server defaults
(translucent white, 1px) that look weak next to the v3.7.2 baseline
(solid white, 2px). Operators upgrading from v3.7.x see a visible
regression on the map.
## What
Restore the v3.7.2 visual as the server default. Customizer + config
plumbing are unchanged — anyone who preferred the thinner translucent
style can dial it back via the in-app customizer (Colors → Marker
Stroke).
| File | Before | After |
|---|---|---|
| `public/style.css` `:root` | `rgba(255,255,255,0.85)` / `1` / `1` |
`#fff` / `2` / `1` |
| `public/customize-v2.js` `msWidth` fallback | `1` | `2` |
| `config.example.json` `markerStroke.color/width` | `rgba(...,0.85)` /
`1` | `#fff` / `2` |
Customizer overrides already in localStorage continue to take effect —
only the unset baseline shifts.
## TDD
- Red commit (`cdabb905`): adds gate F to
`test-issue-1488-marker-stroke-vars.js` asserting style.css /
customize-v2.js / config.example.json defaults match v3.7.2 (solid
white, 2px). Fails on master with 5 assertion errors.
- Green commit (`abfa9b6b`): three small data edits flip all five
assertions to pass.
## Acceptance
- After upgrade, markers visually match v3.7.2 stroke (solid white, 2px)
by default ✅
- Customizer slider still functional ✅
- Existing custom values in localStorage still take effect (no reset) ✅
---------
Co-authored-by: mc-bot <bot@meshcore.local>
## Summary
The version/commit badge currently rendered in the nav stats bar
(alongside packet counts, node counts, and observer counts) is
operator-facing diagnostic information — not something end users need
visible on every page load. For most visitors, it adds visual noise
without adding value.
## Changes
- **perf.js**: Add a **Version** card to the Perf dashboard overview
row. Shows `version` + short `commit` hash, both already available from
`/api/health` (no new API surface needed). Card renders conditionally —
if neither field is set it stays hidden.
- **app.js**: Remove `formatVersionBadge()` and `formatEngineBadge()`
helper functions (now unused); strip the badge call from
`updateNavStats()` so the navbar shows only packet/node/observer counts.
- **style.css**: Remove now-dead `.nav-stats .version-badge`,
`.nav-stats .engine-badge`, and their link sub-rules.
## Rationale
The Perf page is explicitly the right place for this information — it's
already scoped to operators and developers who want to know what version
is running. The navbar is a high-visibility surface shared by all users;
version strings belong in a diagnostic context, not a navigation bar.
Net result: navbar is cleaner for end users; operators can still find
version info immediately on the Perf tab.
Chris Phipps