Configurator UI fails to load in Chrome 147+ over HTTP due to Local Network Access enforcement

[rich5741]

Disclosure - below is AI generated, I ran into the issue and debugged using AI. Personally, I'll go the DuckDNS route eventually

Summary

The Zone Configurator UI fails to load in Chromium-based browsers (Chrome, Edge) when Home Assistant is accessed over HTTP. The page shell loads, but the JS and CSS bundles are blocked by Chrome's Local Network Access (LNA, formerly Private Network Access) policy. The SPA never boots — the user sees a blank/non-functional page.

The configurator works correctly in:

• Home Assistant mobile / desktop apps
• Any browser when HA is accessed over HTTPS (Nabu Casa, Duck DNS + Let's Encrypt, NGINX SSL proxy, etc.)
• Firefox (which has not yet enforced LNA)

Environment

• HA Core: 2026.4.4 (HAOS in Proxmox)
• Zone Configurator add-on: 2026.04.2
• Browser: Chrome 147 (Windows)
• Access URL: http://homeassistant.local:8123

Steps to reproduce

1. Access HA via any HTTP URL (e.g. http://homeassistant.local:8123 or http://<lan-ip>:8123) in Chrome 147+.
2. Settings → Add-ons → Everything Presence Zone Configurator → Open Web UI.
3. Page renders blank. Network requests for index-*.js and index-*.css fail with net::ERR_FAILED.

Browser console output

Access to CSS stylesheet at 'http://homeassistant.local:8123/api/hassio_ingress/.../index-CY-Rr-BP.css'
from origin 'http://homeassistant.local:8123' has been blocked by CORS policy:
The request client is not a secure context and the resource is in more-private address space `local`.

Failed to load resource: net::ERR_FAILED  api/hassio_ingress/.../index-CY-Rr-BP.css

Access to script at 'http://homeassistant.local:8123/api/hassio_ingress/.../index-CWzxAWb2c.js'
from origin 'http://homeassistant.local:8123' has been blocked by CORS policy:
The request client is not a secure context and the resource is in more-private address space `local`.

Failed to load resource: net::ERR_FAILED  api/hassio_ingress/.../index-CWzxAWb2c.js

Root cause

Chrome's Local Network Access policy blocks subresource fetches from non-secure contexts (HTTP) into the "local" address space (.local mDNS hostnames and RFC1918 private IPs). The configurator HTML is served over HA's ingress, which is HTTP — so Chrome refuses to fetch the JS and CSS bundles even though they are same-origin.

Why the main HA frontend isn't affected: it ships a service worker that caches all assets locally, so subsequent loads make zero network requests for JS/CSS — nothing for LNA to gate. Add-on ingress UIs don't get a service worker (and can't easily install one, since service worker registration also requires a secure context), so every asset fetch is a fresh network request that LNA blocks.

Suggested fix (code)

Build the SPA as a single inlined HTML file using vite-plugin-singlefile (assuming Vite, based on the index-<hash>.js / index-<hash>.css output naming). Inlining eliminates separate asset requests entirely — no subresources means nothing for LNA to block.

Tradeoffs:

• HTML payload becomes larger (single file instead of split chunks)
• No per-chunk HTTP caching across loads
• Code splitting / lazy routes stop working

For a configurator that's used occasionally rather than continuously, these are usually acceptable.

Alternative (docs only)

If a code change isn't desirable, a Known Issues note in the README pointing users to one of these workarounds would head off duplicate reports:

• Access HA over HTTPS (Nabu Casa, Duck DNS + Let's Encrypt, NGINX SSL proxy add-on)
• Use Firefox (has not enforced LNA)
• Use the HA mobile / desktop apps
• Whitelist the HTTP origin in chrome://flags/#unsafely-treat-insecure-origin-as-secure (works today, but Google is gradually narrowing this override)

This is likely to start affecting more users as Chrome continues to roll out LNA enforcement.