Web UI fails to load: bundled skiko loader points at a `file:///home/den/...` path from the build machine

[gnllucena]

Version: sndxr/komf:2.0.1 (docker, image built 2026-09-01)
Browser: Firefox 155.0.1 (aarch64)

Opening the Komf web UI shows a blank page. The console reports:

Security Error: Content at http://<host>:8085/ may not load or link to file:///.

followed by a TypeError from the Kotlin/Wasm bootstrap.

The server side is fine: the API answers (/api/config returns the loaded
config), and every UI asset is served correctly with the pre-compressed gzip
files from the jar (komelia-app.js, styles.css, komeliaImageWorker.js,
and the four .wasm files all come back 200 with the right content type).

The cause is in the bundle itself. komelia-app.js (unzipped from
komelia/komelia-app.js.gz in komf-app-1.0.0-SNAPSHOT-all.jar) contains
the emscripten script name of the skiko loader hard-coded to a path on the
build machine:

var i, o = (i = "file:///home/den/Projects/Komelia/build/wasm/packages/komelia-app/kotlin/skiko.mjs", async function(e = {}) { ...

The loader derives its script directory from that string and uses it when
resolving the wasm module (the F = e => e.startsWith("file://") branch, then
the ArrayBuffer fallback). Firefox blocks a page served over http from
touching a file:/// URL, so the module never loads and the UI never renders.

Expected: the loader resolves relative to the page it was served from
(document.baseURI / the webpack public path), as the new URL(..., _.b)
branch already does for the other wasm module.

Steps to reproduce:

1. docker run --rm -p 8085:8085 sndxr/komf:2.0.1
2. open http://localhost:8085 in Firefox 155 with the console open

[Snd-R]

skiko.mjs is merged into komelia-app.js by webpack. the hardcoded path and everything after is the actual content of skiko.mjs
The hardcoded path shouldn't even be used unless somehow emscripten's Module.locateFile was defined which it isn't in the script

I don't know how this is happening for you. I can't reproduce it on any of browsers including Firefox 156. Doesn't happen on mobile either
Does this also happen with other browsers? Maybe some extension is interfering with page script?

[gnllucena]

Found it. Not the file:/// path.

The web UI is Komelia running in the browser, so it connects to Komga and to Komf from the browser, but the addresses it has are the server's.

Komga: it uses komga.baseUri from Komf's config. Mine is http://komga:25600 (docker service name). Komf resolves that, my browser doesn't, so nothing loads and the page stays blank. Changing it to http://192.168.1.102:25600 made the UI appear.

Komf: Komelia's own setting defaults to http://localhost:8085, which is localhost on my Mac. Every API call gets ERR_CONNECTION_REFUSED and the UI shows BrowserConnectionError. Setting it to http://192.168.1.102:8085 fixed it.

Could the web build default the Komf address to the page's own origin? It was served by Komf, so that's always right. And it would be nice to have a config option for the Komga address the browser should use, since in docker it's never the same as the one Komf uses internally. Right now the only way is to put the LAN address in komga.baseUri, which happens to work here.

The Firefox file:/// error is unrelated. Chrome never logs it and everything works there once the two addresses are right.

[Snd-R]

komga address is checked from the perspective of komf container and then reported to browser from komf.
http://komga:25600 should work. it's the komga.baseUri value from komf config