[Bug]: Nothing responds on boot #617

Activity

1. DrSiemer

   added

   bugSomething isn't workingSomething isn't working

   on Sep 10, 2026
2. thcp commented on Sep 10, 2026

   

   thcp

   on Sep 10, 2026

   Collaborator

   More actions

   Thanks for the report. Hovers working but clicks doing nothing points at the WebView2 layer rather than at StemDeck itself, so a couple of things would help narrow it down.

   With StemDeck running, open http://localhost:8000 in Edge or Chrome. Same UI, same backend, just outside the app window. If the buttons work there, the app is fine and the problem is WebView2. If they are dead there too, it is in the page.

   Two other things worth knowing:

   • Your WebView2 runtime version. Settings, Apps, search for "Microsoft Edge WebView2 Runtime".
   • Whether an earlier StemDeck version worked on this machine, or if this is the first one you tried.

   If it is easier to work through it live, I am on Discord: https://discord.gg/YhCKsjhcwB
3. DrSiemer commented on Sep 10, 2026

   

   DrSiemer

   on Sep 10, 2026

   Author

   More actions

   It's my first install (WebView2 runtime version: 152.0.4191.66) and there are a few js errors:

   Failed to load module script: Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.
   ui-chrome.js:1 Failed to load module script: Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.
   :8000/favicon.ico:1  Failed to load resource: the server responded with a status of 404 (Not Found)
   

   It's probably a common registry .js misconfiguration (set as text/plain). That makes Starlette/FastAPI serve the files with Content-Type: text/plain, which makes browsers block the ES modules.

   Windows fix: explicitly register the MIME type near the top of backend/app/main.py.

   import mimetypes
   mimetypes.add_type("text/javascript", ".js")
   mimetypes.add_type("text/css", ".css")
   
4. thcp commented on Sep 12, 2026

   

   thcp

   on Sep 12, 2026

   Collaborator

   More actions

   Thanks for the detail here. "Hovers respond, I can type, but buttons do nothing" is what made this findable, so that was a useful report.

   That combination points at the interface failing partway through starting up. Hovering and text selection are things the browser does on its own. Buttons and file drop need code that attaches to them, and that code never ran.

   StemDeck could not tell you any of that, which is its own problem. The error reporting registers at the end of the same startup run that failed, so when it fails there is nothing to write. That is why your logs look clean. I have opened #618 for it and fixed it, so a future build will show the reason on screen instead of leaving you with a window that ignores you.

   For your install there are two possibilities, and one file tells them apart:

   1. A JavaScript file did not load, usually antivirus quarantine or an incomplete unzip.
   2. Everything loaded and one part threw.

   Could you grab the backend log? With StemDeck open, visit http://127.0.0.1:8080/api/logs/backend (8080 is the default, Settings shows your port). /api/logs.zip gets everything in one file if that is easier.

   What I am looking for is lines mentioning /js/ with a 404. If one is there, it names the missing file and a clean re-extract fixes it. If they are all 200, it is mine to chase and I will take it from there.

   Let me know what you find.
5. thcp commented on Sep 12, 2026

   

   thcp

   on Sep 12, 2026

   Last edited by thcp

   Collaborator

   More actions

   That is it exactly, and thank you for digging into it. Your console output named the cause outright.

   You are right about where it comes from. mimetypes reads HKEY_CLASSES_ROOT on Windows, so a .js entry pointing at text/plain makes Starlette serve every module as plain text, and the browser refuses to execute them. Nothing attaches, and what is left is a window that renders and ignores you. That also explains why the logs were clean. Every request returned 200.

   Fixed in #620, along the lines you suggested. The types the app serves are now pinned at startup, so the registry no longer gets a vote.

   You had already posted the answer two days earlier, and my last comment asked for logs anyway. Noted for next time.

   Separately, #619 addresses why this reached you as a silent failure at all. The error reporting was registering at the end of the same startup run that was failing, so there was nothing to write. With that in, this would have told you what broke instead of leaving you guessing.

   Both are on main shortly and will be in the next release. If you would rather not wait, setting .js back to text/javascript in the registry fixes your install today.

   Thanks again. This was a good catch.
6. thcp

   closed this as completedin #620on Sep 12, 2026
7. thcp

   added a commit that references this issue on Sep 12, 2026

   Say why the app did not start, instead of showing a dead one (#619)

   ...

   ddc0b43
8. tranzmatt

   added a commit that references this issue on Sep 12, 2026

   Serve the frontend with correct MIME types, whatever the host registr…

   ...

   This issue will close once commit db154b8 is merged into the 'main' branch.

   db154b8
9. thcp

   self-assigned this

   on Oct 1, 2026