Tracker: bug reports from the field

[barrulus]

Running log of user-reported bugs, their diagnosis, and where the fix landed. One comment per new report; edit the tables as status changes.

Fixed

Reported	Bug	Root cause	Fix	Status
2026-08-22, Discord (map `0 2026-08-22-21-11.map`)	Dragging an iceberg freezes/"crashes" the tab on ice-heavy maps (~1.2s per mouse-move with 12,380 ice shapes)	`#ice` was one flat SVG group with no viewport culling; moving one polygon re-rasterized every sibling. Also: drag attached to every shape while writing offsets to the selected one (data corruption), `.on("drag")` wiring made the shape trail one event behind the cursor, O(n²) `getNextId`	#31 — viewport-culled ice layer + editor drag rewiring; write-up in `docs/superpowers/specs/2026-08-22-bug-iceberg-drag-freeze.md`	Merged to main (f89ec75)
2026-08-23, same reporter/map	Deleting rivers leaves all river labels behind (fork only; upstream clean)	Sync gap, not a new bug: our fix went upstream as Azgaar#1600 (merged, 1.148.x) but no fork PR was ever opened, and it missed the 1.147.1 sync point	#32 — clean cherry-pick of the same commit onto fork main	Merged to main (f03a374)
2026-09-03, Discord (DietCholera, map The Flames, saved on 1.139.4)	Hamlet, village, trading post, monastery and fort labels never appear at any zoom after loading on 1.150	The 1.140 migration harvested the legacy zoom auto-visibility display: none from each burg tier's style attribute into the persisted label group style; the 1.150 store migration kept it, and the store is applied over the saved svg on load, so re-saving never sheds it. Upstream issue Azgaar#1773	Strip display in the harvest funnel (labelStyleFromLegacy) plus a 1.151.2 migration pass over the stored label group styles for maps saved by 1.150-1.151.1. Fork #66; upstream Azgaar#1802	Merged to fork main (da86d21, 1.151.2-fork.1); upstream PR open

Open / awaiting info

Reported	Bug	Root cause	Fix	Status
2026-08-30, Discord (volley, Electron desktop v1.149.1)	"New version released" dialog pops up every time a note is added to an object; cosmetic only, the note editor still works	onChunkLoadError (src/services/app-shell.ts) shows the reload dialog on any vite:preloadError. That assumption only holds for the hosted web build — in the packaged desktop app every chunk ships with the bundle, so the modulepreload of the notes-editor chunk fails under the Electron protocol while the import() itself succeeds	Reported upstream as Azgaar#1660; suggested gating the dialog on an http(s) origin or on the import actually failing	Upstream issue open, no fork PR yet
2026-09-03, same reporter (second cause in the same report)	Newly generated maps have zero labels in that browser, forever; loaded old maps unaffected	localStorage["options-labels"] (and burg-groups) is seeded into options unvalidated at boot and again in randomizeOptions(); a stale {groups: []} from an earlier build empties the label group registry. Upstream issue Azgaar#1771	Validate the stored registries and rebuild a type that lost all of its groups. Upstream Azgaar#1801	Upstream PR open, no fork PR yet. Workaround: Label Groups editor → Restore, or DevTools → Application → Clear site data (hard reload does not clear localStorage)

Closed — not a bug

Reported	Observation	Resolution
2026-08-22, same map	`pack.goods` is `[]` and `cells.good` all-zero while markets/deals/production still reference goods 1–71 — catalogue emptied after generation. Audit: `docs/superpowers/specs/2026-08-22-map-audit-0.md`	Confirmed intentional (2026-08-27): reporter cleared the catalogue deliberately. In-app recovery if ever wanted: Goods editor → Restore defaults (re-rolls placement + economy)

Related knowledge

• 1.140 migration bakes transient zoom display: none into persisted label group styles Azgaar/Fantasy-Map-Generator#1773 / Stale localStorage options-labels silently removes labels from all newly generated maps Azgaar/Fantasy-Map-Generator#1771 — the two halves of the 2026-09-03 "labels missing" report; the file was never damaged, the missing labels/emblems/trade/threeD option keys in an old file are synthesised by migration
• Knowledge: "version-lie" maps — ancient map data behind a modern version line skips all migrations (manual repair recipe) #30 — "version-lie" maps: ancient data behind a modern version line skips all migrations (manual repair recipe, same reporter's other map)

[barrulus]

SVG export opens blank in Inkscape (Discord, Lski3, 2026-08-26)

Symptom: exported SVG is completely blank in Inkscape, fine in browsers. Reporter also found a data:text/html;base64,... (GitHub Pages 404 page) embedded as the oceanicPattern image.

Diagnosed — two independent defects, both reproduced locally:

1. Blanker (root cause): global Style filters (Tint etc.) are applied as filter="url(#filter-tint)" on the root <svg id="map"> and exported verbatim. Inkscape (verified on 1.4.4) renders any real exported document with a filter on the root svg element as fully blank. Verified fix direction: at SVG export time, move the filter attribute from the root onto the #viewbox group — full map then renders in Inkscape with the tint applied, and browsers render it identically. Masks are NOT the cause (Azgaar's guess) — exports render fine in Inkscape 1.4.4 once the root filter moves.

2. Cosmetic: getBase64 (src/utils/commonUtils.ts:146) inlines whatever the ocean-pattern URL returns with no status/content-type check, so a 404 HTML page gets embedded as the image. Confirmed: azgaar.github.io/images/pattern1.png → GitHub 404 page matching the reporter's decoded base64. Fix: only inline 2xx + image/* responses.

Full diagnosis with repro method: docs/superpowers/specs/2026-08-26-svg-export-inkscape-blank.md (uncommitted on feat/marker-icon-svg-defaults working tree). Both defects exist upstream too (modules/io/export.js) — upstream-worthy fixes, target TBD.

[barrulus]

Update: fix implemented on branch fix/svg-export-inkscape (commit 8a029db, local only — not yet pushed/PR'd).

Implementation revealed the relocation alone is insufficient: with default filter regions Inkscape miscomposites the big filtered group racily (same file flips between clean, blank, and black-blob renders across repeated opens — its multithreaded filter renderer). Final fix = relocate root filter to #viewbox + explicit filterUnits=userSpaceOnUse x=0 y=0 width=100% height=100% on every filter def at export time. Measured: 0% usable before → 15/16 and 5/5 clean renders on the two pathological test maps; residual ~5% is Inkscape-internal and fixed by re-opening the file. getBase64 now refuses non-2xx/non-image responses and the export drops the pattern/texture image instead of embedding error pages (a dead href renders as a dark broken-tile grid in Inkscape).

7 new unit tests; full suites green fork (778) and upstream port (428 — upstream master is already on the src/ layout, port is near-1:1, held locally pending go-ahead). Spec updated: docs/superpowers/specs/2026-08-26-svg-export-inkscape-blank.md.

[barrulus]

Landed as PRs: fork #43 (base main) and upstream Azgaar#1646 (base 1.149.0, rebased onto that version branch — only merge delta was coexisting with the new parseError tests in commonUtils.test.ts). Both verified green on their respective bases (fork 778 tests, upstream 437).

[barrulus]

Second Inkscape defect found via field testing (user's own Inkscape session): map icons render hundreds of times too large — giant black blobs covering the map. Cause: burg/anchor/goods/relief icons are use→symbol references sized by the symbol's 1em width against the group font-size; Inkscape can't resolve that and falls back to viewport-sized icons. "No Filters" display mode doesn't help (it's not the filter bug).

Fix pushed to both PRs (fork #43 commit 3d5d998, upstream Azgaar#1646 commit 924c08f): flattenSymbolReferences at SVG export bakes the viewBox math into a transform per use and converts symbols to plain groups — no symbol sizing semantics left for any renderer to get wrong. Also dedupes the per-burg-group symbol defs (duplicate ids). 8 new unit tests (em sizing incl. inlined font: shorthand, explicit use w/h, viewBox min offsets, meet centering); Inkscape 3/3 identical clean renders with correct icon sizes; Chromium unchanged.

[barrulus]

Note on sequencing: #43 merged before the icon-scaling fix was pushed, so fork main currently has only the filter/getBase64 half. The icon flattener is now up as #44 (single commit 3d5d998c on top of merged main). Upstream Azgaar#1646 carries both halves in one PR.

[barrulus]

New report — 2026-08-30, Discord (volley), Electron desktop client v1.149.1.

getting this error any time i want to add a note to something. electron client v1.149.1 [...] doesn't seem to affect anything functionally but it's an annoying popup

Adding a note to any object raises the "New version released" dialog ("This part of the app failed to load because a new version was released while the page was open"). Purely cosmetic — the note editor works.

Diagnosis: onChunkLoadError in src/services/app-shell.ts listens for vite:preloadError and unconditionally offers a reload. That assumption ("a release replaced the content-hashed chunks on the server") is only true for the hosted web build; in the packaged desktop app the chunks ship with the bundle, so the modulepreload of the notes-editor chunk fails under the Electron file/app protocol while the dynamic import() still succeeds.

Suggested fix: gate the dialog on an http(s) origin, or confirm the import actually failed before offering a reload.

Reported upstream: Azgaar#1660 (screenshot attached there). Affects the fork identically — same file, same listener.

[barrulus]

New report — 2026-09-03, Discord (DietCholera), map The Flames, originally saved on 1.139.4, loaded on 1.150.0.

Symptom: "labels missing", plus the labels, emblems, trade and threeD option sections absent from the .map. The file was never damaged; keys that post-date the file's version are synthesised by migration. Two independent bugs were in play, which is what made it look like corruption:

1. Loaded old maps: burg tiers hidden at every zoom — 1.140 migration bakes transient zoom display: none into persisted label group styles Azgaar/Fantasy-Map-Generator#1773. The 1.140 migration harvested the legacy zoom auto-visibility display: none from each tier's style attribute into the persisted label group style. Since 1.150 the styles store is applied over the saved svg on load, so clearing the DOM and re-saving does not help; the stored string has to be cleaned. Fix: strip display in the harvest funnel and add a 1.151.2 migration pass over stored label group styles. Fork fix: strip zoom auto-visibility display from migrated label group styles #66 merged (da86d21, fork main now 1.151.2-fork.1); upstream fix: strip zoom auto-visibility display from migrated label group styles Azgaar/Fantasy-Map-Generator#1802 open. Verified on the reporter's original file and the 1.150.0 re-save against an unfixed baseline.
2. New maps: zero labels in that browser — Stale localStorage options-labels silently removes labels from all newly generated maps Azgaar/Fantasy-Map-Generator#1771. Stale localStorage["options-labels"] is seeded into options unvalidated, at boot and again in randomizeOptions(). Fix upstream as fix: validate the stored label and burg group registries Azgaar/Fantasy-Map-Generator#1801 (open); no fork PR yet. User workaround: Label Groups editor → Restore, or DevTools → Application → Clear site data.

The two PRs touch different structures and were load-tested together on both of the reporter's files. Tables updated.