From bd7d5a19c1625ce52a100fa6281437c7b8e8311b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Roland=20B=C3=BCrgi?= Date: Wed, 26 Aug 2026 17:28:24 +0200 Subject: [PATCH 1/3] What's New: a map that cannot load says so MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Release note for the OpenStreetMap renderer fix that lands in Systemorph/MeshWeaver.Plugins#710 — the code lives in that repo (the pack, and the Blazor host it builds on, both moved out of core), the issues live here. Two user-visible changes in one: a map that cannot be drawn now replaces its empty rectangle with the platform's message-bar surface — title, reload hint, and the exact URL that did not resolve under Details — instead of leaving a blank box indistinguishable from one still loading (#2384); and leaving a page while its maps are still drawing is recorded as the routine cancellation it is rather than at Error, so what remains under that heading is real (#2381). Closes #2384 Closes #2381 --- ...26-08-26-a-map-that-cannot-load-says-so.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md diff --git a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md new file mode 100644 index 0000000000..5849320d6f --- /dev/null +++ b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md @@ -0,0 +1,24 @@ +--- +Name: A map that cannot load says so +Category: Fix +Description: An OpenStreetMap map that fails to draw now explains itself on the page instead of leaving an empty box, and navigating away mid-draw is no longer recorded as a failure. +Icon: Globe +Order: -20260826 +--- + +# A map that cannot load says so + +When an OpenStreetMap map could not be drawn, the page showed an empty rectangle. Nothing said +whether the map was still loading, had nothing to show, or had failed outright — and the only +record of what had actually happened was a server log the viewer cannot read. On a page with +several maps, all of them looked the same: blank. + +A map that cannot be drawn now replaces that empty rectangle with a short message saying the view +failed to render, suggesting a reload, and offering the technical reason under **Details** — the +exact address that could not be fetched, so the problem can be reported and fixed instead of +guessed at. + +The other half of the change is about the logs. Leaving a page while its maps are still being drawn +cancels that work, which is entirely routine — but it was being recorded with the same severity as +a map that genuinely failed to build. Ordinary navigation is now recorded as what it is, which +means the remaining entries under this heading are real failures worth looking at. From 2ff3f4488a6feb4e28240dda496f1df1b230cec0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Roland=20B=C3=BCrgi?= Date: Wed, 26 Aug 2026 17:31:58 +0200 Subject: [PATCH 2/3] What's New: match the wording to the surface actually rendered The pack reuses the portal's existing render-error notice rather than a message bar with a Details accordion, so the note should not promise one. --- .../2026-08-26-a-map-that-cannot-load-says-so.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md index 5849320d6f..71108b011e 100644 --- a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md +++ b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md @@ -1,7 +1,7 @@ --- Name: A map that cannot load says so Category: Fix -Description: An OpenStreetMap map that fails to draw now explains itself on the page instead of leaving an empty box, and navigating away mid-draw is no longer recorded as a failure. +Description: An OpenStreetMap map that fails to draw now explains itself on the page instead of leaving an empty box, and leaving a page mid-draw is no longer recorded as a failure. Icon: Globe Order: -20260826 --- @@ -13,10 +13,10 @@ whether the map was still loading, had nothing to show, or had failed outright record of what had actually happened was a server log the viewer cannot read. On a page with several maps, all of them looked the same: blank. -A map that cannot be drawn now replaces that empty rectangle with a short message saying the view -failed to render, suggesting a reload, and offering the technical reason under **Details** — the -exact address that could not be fetched, so the problem can be reported and fixed instead of -guessed at. +A map that cannot be drawn now replaces that empty rectangle with the same short notice the portal +already shows for any view that fails to render: what happened, a suggestion to reload, and the +technical reason — including the exact address that could not be fetched, so the problem can be +reported and fixed instead of guessed at. The other half of the change is about the logs. Leaving a page while its maps are still being drawn cancels that work, which is entirely routine — but it was being recorded with the same severity as From 03d08a34626cf9777659721fb53d770a06798a27 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Roland=20B=C3=BCrgi?= Date: Wed, 26 Aug 2026 17:38:38 +0200 Subject: [PATCH 3/3] =?UTF-8?q?What's=20New:=20cover=20the=20third=20fix?= =?UTF-8?q?=20=E2=80=94=20maps=20had=20no=20height,=20so=20none=20were=20v?= =?UTF-8?q?isible?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The note now leads with the change a viewer actually notices (maps appear at all), and renamed to match. Verified: MeshWeaver.Documentation.Test rebuilt in Release (the note ships as an embedded resource) then WhatsNewEntryIntegrityTest + DocumentationLinkIntegrityTest — 2 passed. --- ...26-08-26-a-map-that-cannot-load-says-so.md | 24 ----------------- ...8-26-openstreetmap-maps-actually-appear.md | 27 +++++++++++++++++++ 2 files changed, 27 insertions(+), 24 deletions(-) delete mode 100644 src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md create mode 100644 src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-openstreetmap-maps-actually-appear.md diff --git a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md deleted file mode 100644 index 71108b011e..0000000000 --- a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-a-map-that-cannot-load-says-so.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -Name: A map that cannot load says so -Category: Fix -Description: An OpenStreetMap map that fails to draw now explains itself on the page instead of leaving an empty box, and leaving a page mid-draw is no longer recorded as a failure. -Icon: Globe -Order: -20260826 ---- - -# A map that cannot load says so - -When an OpenStreetMap map could not be drawn, the page showed an empty rectangle. Nothing said -whether the map was still loading, had nothing to show, or had failed outright — and the only -record of what had actually happened was a server log the viewer cannot read. On a page with -several maps, all of them looked the same: blank. - -A map that cannot be drawn now replaces that empty rectangle with the same short notice the portal -already shows for any view that fails to render: what happened, a suggestion to reload, and the -technical reason — including the exact address that could not be fetched, so the problem can be -reported and fixed instead of guessed at. - -The other half of the change is about the logs. Leaving a page while its maps are still being drawn -cancels that work, which is entirely routine — but it was being recorded with the same severity as -a map that genuinely failed to build. Ordinary navigation is now recorded as what it is, which -means the remaining entries under this heading are real failures worth looking at. diff --git a/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-openstreetmap-maps-actually-appear.md b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-openstreetmap-maps-actually-appear.md new file mode 100644 index 0000000000..a5783ac4a2 --- /dev/null +++ b/src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-26-openstreetmap-maps-actually-appear.md @@ -0,0 +1,27 @@ +--- +Name: OpenStreetMap maps actually appear +Category: Fix +Description: OpenStreetMap maps are drawn at a usable size instead of collapsing to nothing, a map that cannot load explains itself on the page, and leaving a page mid-draw is no longer recorded as a failure. +Icon: Globe +Order: -20260826 +--- + +# OpenStreetMap maps actually appear + +An OpenStreetMap map used to leave an empty rectangle on the page, and nothing said why. Three +separate reasons could produce that same blank box, and none of them told the viewer anything. + +**The map now has a size.** A map is drawn into whatever space its container has, and that container +had no height at all unless the page author happened to give it one — so a map that had loaded +perfectly and was working correctly was still nothing to look at. It now comes with a sensible +default height, and a page that wants a different one still just says so. + +**A map that cannot be drawn explains itself.** Where the map's own drawing code cannot be fetched, +the page now shows the same short notice the portal already uses for any view that fails to render: +what happened, a suggestion to reload, and the technical reason — including the exact address that +could not be fetched, so the problem can be reported and fixed instead of guessed at. + +**Leaving the page is no longer a failure.** Navigating away while maps are still being drawn +cancels that work, which is entirely routine — but it was being recorded with the same severity as +a map that genuinely failed. Ordinary navigation is now recorded as what it is, which means what +remains under that heading is worth looking at.