[Bug] Wrong MIME Type for WebUI #767
Labels
bug
Something isn't working
Comments
|
This is something we fixed in r1424, I am skeptical since it should be fixed, are you sure you are using r1424 on fedora? |
|
Yes, I tested with both r1197 and r1424, same results. I also just tested them with OpenJDK 17.0.2 to see if it was something to due with the java version, but no difference I could find. I double-checked the console output and it contains this: EDIT: Ok, I just tested r1424 on a clean install of Fedora KDE 39(not Kinoite), and it worked as expected, so something Fedora does with regards to their immutable systems might be the cause. |
|
Have the same issue in Fedora Onyx, also an immutable spin of Fedora, but not on Arch and Ubuntu. |
|
can you reproduce the issue with the latest preview version, enabled debug logs (via launcher or server.conf, requires server restart to take effect) and then provide the logs (logs folder in the root dir https://github.com/Suwayomi/Tachidesk-Server/wiki/The-Data-Directory) |
|
Here's the logs, issue still persists (debug logs enabled, WebUI channel is 'preview'). |
|
does the server create a webUI dir inside the root dir and is there content inside of it, according to the logs it should exist? |
|
The WebUI directory is created, and the server correctly downloads the WebUI to it if it's empty. Manually extracting the WebUI preview to the directory gives off the same errors as before. I tested the sorayomi WebUI to see if it would make a difference. I got a similar result, but the page was the same light blue as sorayomi's startup: |
|
what does the server respond with for the different requests (browser dev tools)? |
|
Here's what I got: |
|
just to make sure, there is a |
|
Yeah, the folder and the files exist. |
|
Ok, I tested Tachidesk on the other official Fedora immutable desktops. |
|
I encountered this error since the 1.0.0 release. Device information
Steps to reproduceI run this command ( #!/bin/sh
PWD=$HOME/suwayomi
exec /usr/bin/java \
-Dsuwayomi.tachidesk.config.server.systemTrayEnabled=false \
-Dsuwayomi.tachidesk.config.server.initialOpenInBrowserEnabled=false \
-Dsuwayomi.tachidesk.config.server.rootDir=$PWD/data \
-Dsuwayomi.tachidesk.config.server.downloadsPath=$PWD/dl \
-Dsuwayomi.tachidesk.config.server.webUIEnabled=true \
-Dsuwayomi.tachidesk.config.server.webUIInterface=browser \
-Dsuwayomi.tachidesk.config.server.webUIFlavor=WebUI \
-Dsuwayomi.tachidesk.config.server.ip=0.0.0.0 \
-Dsuwayomi.tachidesk.config.server.port=3000 \
-Dsuwayomi.tachidesk.config.server.downloadAsCbz=true \
-jar $PWD/suwayomi.jarOutput
browser blank page<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<link rel="icon" href="/favicon.ico"/>
<meta name="viewport" content="minimum-scale=1, initial-scale=1, width=device-width"/>
<meta name="theme-color" content="#000000"/>
<meta
name="description"
content="A manga reader that runs tachiyomi's extensions"
/>
<link rel="apple-touch-icon" href="/favicon.png"/>
<!--
manifest.json provides metadata used when your web app is installed on a
user's mobile device or desktop. See https://developers.google.com/web/fundamentals/web-app-manifest/
-->
<link rel="manifest" href="/manifest.json"/>
<title>Suwayomi</title>
<script type="module" crossorigin src="/assets/index-K7hopUq-.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-S3GDysPx.css">
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div>
<!--
This HTML file is a template.
If you open it directly in the browser, you will see an empty page.
You can add webfonts, meta tags, or analytics to this file.
The build step will place the bundled scripts into the <body> tag.
To begin the development, run `npm start` or `yarn start`.
To create a production bundle, use `npm run build` or `yarn build`.
-->
</body>
</html>application log |
|
After coming back to this last week, I believe I found the problem. In short, atomic versions of Fedora set $HOME to /var/home, and symlinks /home to it. However, aside from Silverblue, they create users during installation, and that change has not yet been added to the installer, so initial users still have $HOME as /home (users created after install are not affected). My wonder is why this is an issue; there should be no functional difference between the two, and other programs I use work as they should with this 'bug'. Maybe symlinks break how the server delivers files? |
|
Interesting! I backed up my Tachidesk directory on an external repo, and was symlinking it to Instead, I used this: And this works! Thanks for your findings. The weird part is that symlinking the directory from an external disk worked on another setup (Arch) but not on this one (Ubuntu). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Device information
Steps to reproduce
Expected behavior
The web ui should load normally.
Actual behavior
The tab Tachidesk opens is blank, accessing other pages via url gives the same result. Firefox's console shows:
The stylesheet "http://127.0.0.1:4567/static/css/2.8c49bb0a.chunk.css" was not loaded because its MIME type, "text/html", is not "text/css". The stylesheet "http://127.0.0.1:4567/static/css/main.efc3b6a7.chunk.css" was not loaded because its MIME type, "text/html", is not "text/css". The script from "http://127.0.0.1:4567/static/js/2.8953c29e.chunk.js" was loaded even though its MIME type ("text/html") is not a valid JavaScript MIME type. The script from "http://127.0.0.1:4567/static/js/main.9b92ea11.chunk.js" was loaded even though its MIME type ("text/html") is not a valid JavaScript MIME type. Uncaught SyntaxError: expected expression, got '<' Uncaught SyntaxError: expected expression, got '<'Other details
I have tried deleting all files in the WebUI folder and restarting, as well as using the Sorayomi and preview WebUI. This was tested with both preinstalled and flatpak Firefox. I tested in a VM and on a HP laptop; both were clean installs.
My personal server on Arch Linux has not faced this issue, so I presume it has something to do with Fedora.
The text was updated successfully, but these errors were encountered: