fix(mermaid): wacht op pagina-klaar vóór renderen op macOS-WebView (#882) #887

Merged

brenno merged 3 commits from fix/882-mermaid-macos-render into main

2026-07-26 13:09:50 +00:00

brenno commented

2026-07-26 13:09:48 +00:00

Owner

Op macOS-desktop renderde geen mermaid-diagram (grijs kader met broncode) en was de PDF/PPTX-export van diagram-dia´s leeg. Oorzaak: een opstartrace. loadHtmlString resolvet zodra het laden START; _bootstrapped=true werd dan meteen gezet en de wachtrij vuurde runJavaScript(´window.__renderMermaid(...)´) af — maar die functie wordt pas een tel later gedefinieerd wanneer het 3,4MB-pagina-script draait, dus die vroege renders raakten FWFEvaluateJavaScriptError.

Diagnostiek (via een nieuw JS-channel) bevestigde dat mermaid wél laadt en rendert op WKWebView (setup-ok mermaid=object render=function); de fout viel steeds vóór dat signaal.

Fix: de WebView-pagina meldt setup-ok zodra mermaid geladen en __renderMermaid gedefinieerd is; de dienst geeft de renderwachtrij pas dán vrij (met een 10s-time-out-vangnet), niet meer bij het resolven van loadHtmlString. De render stuurt zijn resultaat via het channel terug i.p.v. een Promise via runJavaScriptReturningResult.

Verificatie: make check groen; de pipeline-test (mermaid_render_pipeline_test.dart) bootst het channel + de setup-ok-handshake na (9/9). Beeldkeuring op de draaiende macOS-app: geen FWFEvaluateJavaScriptError meer, diagrammen renderen vanaf de eerste weergave, PDF-export niet meer leeg. 5 van de 7 diagramtypen renderen correct.

Bekend restant, apart getrackt: erDiagram en gantt renderen nog niet (type-specifiek, stille fallback) — zie #886. Staat los van deze race-fix.

fixes #882

Op macOS-desktop renderde geen mermaid-diagram (grijs kader met broncode) en was de PDF/PPTX-export van diagram-dia´s leeg. **Oorzaak: een opstartrace.** `loadHtmlString` resolvet zodra het laden START; `_bootstrapped=true` werd dan meteen gezet en de wachtrij vuurde `runJavaScript(´window.__renderMermaid(...)´)` af — maar die functie wordt pas een tel later gedefinieerd wanneer het 3,4MB-pagina-script draait, dus die vroege renders raakten `FWFEvaluateJavaScriptError`. Diagnostiek (via een nieuw JS-channel) bevestigde dat mermaid wél laadt en rendert op WKWebView (`setup-ok mermaid=object render=function`); de fout viel steeds vóór dat signaal. **Fix:** de WebView-pagina meldt `setup-ok` zodra mermaid geladen en `__renderMermaid` gedefinieerd is; de dienst geeft de renderwachtrij pas dán vrij (met een 10s-time-out-vangnet), niet meer bij het resolven van `loadHtmlString`. De render stuurt zijn resultaat via het channel terug i.p.v. een Promise via `runJavaScriptReturningResult`. **Verificatie:** `make check` groen; de pipeline-test (`mermaid_render_pipeline_test.dart`) bootst het channel + de setup-ok-handshake na (9/9). Beeldkeuring op de draaiende macOS-app: geen `FWFEvaluateJavaScriptError` meer, diagrammen renderen vanaf de eerste weergave, PDF-export niet meer leeg. 5 van de 7 diagramtypen renderen correct. **Bekend restant, apart getrackt:** erDiagram en gantt renderen nog niet (type-specifiek, stille fallback) — zie #886. Staat los van deze race-fix. fixes #882

brenno added 3 commits

2026-07-26 13:09:48 +00:00

fix(mermaid): render op macOS-desktop via een JS-channel i.p.v. een Promise (#882 ) 84cdebf540

mermaid.render is async; runJavaScriptReturningResult marshalt het teruggegeven
Promise niet op macOS-WKWebView (FWFEvaluateJavaScriptError), waardoor elk
diagram op desktop leeg bleef en de PDF/PPTX-export van diagram-dia's ook. De
WebView stuurt de klaar-gerenderde SVG nu via een MermaidChannel terug; _run
vuurt de render met runJavaScript en wacht op dat bericht (gekoppeld via een
seq, met time-out). De pipeline-test bootst het channel na.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

diag(mermaid): meld setup-uitkomst + typeof mermaid via channel (#882 ) b77a8c20bd

De setup-keten in de WebView-pagina staat nu in try/catch en meldt bij pageload
via MermaidChannel of hij slaagde ('setup-ok' met typeof mermaid/__renderMermaid/
inliner) of anders wélke fout hem brak ('setup-error'). Zo is met één
beeldkeuring-ronde vast te stellen of de inline-setup draait en of de
mermaid-bundel laadt op WKWebView — de oorzaak van #882 zit dieper dan het
Promise-marshalen (runJavaScript negeert dat juist).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

fix(mermaid): wacht op pagina-klaar vóór renderen op WebView (#882 )

scans / scans (pull_request) Successful in 3m30s

Details

a3791a4dfb

De echte oorzaak was een opstartrace, geen Promise-marshalen: loadHtmlString
resolvet zodra het laden START, waarna _bootstrapped=true werd gezet en de
wachtrij meteen renders afvuurde. Maar window.__renderMermaid wordt pas een tel
later gedefinieerd (als het 3,4MB-pagina-script draait), dus die vroege renders
raakten FWFEvaluateJavaScriptError -> grijs vlak + lege PDF-export. Diagnostiek
bevestigde: setup slaagt (mermaid=object, render=function), diagrammen renderen
ná setup-ok. De dienst wacht nu op het setup-ok-bericht van de pagina (met een
time-out-vangnet) vóór het de wachtrij vrijgeeft.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 55c5c8b9cd into main

2026-07-26 13:09:50 +00:00

brenno referenced this pull request from a commit

2026-07-26 13:09:53 +00:00

Merge pull request 'fix(mermaid): wacht op pagina-klaar vóór renderen op macOS-WebView (#882)' (#887) from fix/882-mermaid-macos-render into main