-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4.42.0 shows no UI on Linux #2684
Comments
Hi So it works in 4.41 but it is a regression in 4.42? 🤔 Could you try running this:
Then opening http://127.0.0.1:23456/, clicking BitBoxApp, then Console, and copying all the output there? Maybe there is a relevant error message there. |
Yes, it's a regression. The console says a very interesting thing: |
x-matlab, that is quite mysterious. It is not quite clear to me if the index JS file could not be loaded, or if the index.js file tried to load something which failed. The index.js file is loaded as a local resource by QtWebEngine, that should be no problem 🤔 Can you check the Network tab in the developer console? Is there any resource shown there? |
How about the output of:
|
Note that the problem exists in the .AppImage too which should be not dependent on my system. |
When I reload the dev tools (after a working UI), I get: and the app shows "Your file was not found". It is strange that it behaves differently for us, seeing that the WebEngine libraries are bundled and the asset is loaded statically. This is why I had thought that maybe your app may have accidentally linked to another lib. What if you tried this anyway just to rule it out:
or ran the BitBox from the local folder:
? |
For me it shows the correct mimetype text/javascript. Browsing commits since 4.41.0, the only potentially relevant commits could be and Though I don't really see how they could change the mimetype - I thought the mimetype is determined by Chromium by the Are you able to build the app yourself? If not, I can try to make builds for your reverting these commits to see if they caused it. Maybe you could also try running it in a VirtualBox VM or Ubuntu Liveboot, just to see if there is something on your system that could be interfering. |
Still works after update. I'll try to build the app later. |
I also don't have matlab/octave installed and have similar results in the /usr/share folder. |
I initialized a docker environment and am currently bisecting it testing appimages. The master version is broken, 4.41.0 works. |
Bisect says it's b6749d4 as you assumed. So what now? |
I believe the relevant dependency in b6749d4 is vite all others are only for types, linting and testing. I'll try to make a quick test and compare the unminified build (
In this case you could just delete and recreate the package-lock.json by |
I think it wouldn't do what's expected (I just tried and nothing changed). Many dependencies are specified as a caret range |
attached is a gist with the diff of JS and HTML file of the 2 unminified versions, using diff --git a/frontends/web/vite.config.mjs b/frontends/web/vite.config.mjs
index b012fd3a3..ea2a3b3b7 100644
--- a/frontends/web/vite.config.mjs
+++ b/frontends/web/vite.config.mjs
@@ -11,6 +11,14 @@ export default defineConfig(() => {
build: {
modulePreload: false,
outDir: 'build',
+ minify: false,
+ rollupOptions: {
+ output: {
+ entryFileNames: 'assets/[name].js',
+ chunkFileNames: 'assets/[name].js',
+ assetFileNames: 'assets/[name].[ext]',
+ }
+ }
},
plugins: [
react(), https://gist.github.com/thisconnect/ceea8d1935c126a66447bb7fc0289ac4 |
Probably the problem is this: https://bugs.archlinux.org/task/80279 Still not sure why it works fine in the VM with the same package version. Maybe something else is triggering the bug? |
After minification, the working file function __vite__mapDeps(indexes) {
if (!__vite__mapDeps.viteFileDeps) {
__vite__mapDeps.viteFileDeps = []
}
return indexes.map((i) => __vite__mapDeps.viteFileDeps[i])
} The word |
Wow, great debugging! ⭐ And what a crazy and unlikely bug too 🤯 I quickly tried browsing the qtwebengine source to see how the mimetype is determined, but I couldn't figure it out.
Maybe you can find the difference in the mime files between the two systems, and maybe there are some commands that can list packages that touch these files that you could run. In any case, now we need to decide what to do about this. Options are:
Any other ideas? |
Both systems now run Debian testing and the package versions are identical, at least I'd like to try a Qt update, not sure how to do it properly for docker build. I changed the Qt version to We don't know if this bug is rare, we'll see in the next few days because 4.42.0 was just released, maybe not many people updated yet. I'd really like to know how |
I haven't verified but it seems likely that this is the code that identifies the mimetype: Which would be this method: https://doc.qt.io/qt-5/qmimedatabase.html#mimeTypeForFile With the default match mode:
In the Qt codebase, this would be this line: https://github.com/qt/qtbase/blob/v5.15.2/src/corelib/mimetypes/qmimedatabase.cpp#L577 which calls this function? https://github.com/qt/qtbase/blob/v5.15.2/src/corelib/mimetypes/qmimedatabase.cpp#L355 which only looks at the content if the extension yields multiple candidates. A newer Qt version has different code, https://github.com/qt/qtbase/blob/v6.7.0/src/corelib/mimetypes/qmimedatabase.cpp#L492 Again, I was just browsing code. To verify, you'd have to call
|
@rkfg could you build and test this branch to see if it solves your problem? It forces mime type resolution by extension only: https://github.com/benma/bitbox-wallet-app/tree/mimetype/ As predicted above, it is quite a bit of weird code to accomplish this, but it's worth a try. |
Nice, this version with mime patch works well! Although it's clearly a hacky solution, I'd rather find the real reason. Thanks for the pointers ( 😉 ), I'll take a look and experiment with debug prints. Tried this: #include <QCoreApplication>
#include <QFile>
#include <QFileInfo>
#include <QMimeDatabase>
#include <QDebug>
int main(int argc, char *argv[])
{
QFile file("index-cNUc17VX.js");
QFileInfo fileInfo(file);
file.open(QFile::ReadOnly);
QMimeDatabase mimeDatabase;
QMimeType mimeType = mimeDatabase.mimeTypeForData(file.readAll());
qInfo() << mimeType.name();
return 0;
} Using the file I saved from the app. It returns |
You might be onto something here. Too bad there's absolutely no debug output in that function so it's not possible to find if it found more than one candidate by extension. Oh wtf, I solved it 😂 This is indeed what caused it, I grepped
It belongs to the My monodevelop version is 5.10.0.871-2, it seems to be a very old version from 2015. However, I downloaded a .deb for the last version they have (from 2019) and it also has the same xml file with the same contents, at least the *.js part is present. |
Anyway, great job finding the culprit! Now I still don't know whether we should pursue the above patch or leave it as it is 😁 |
Yeah, that's a tricky question. There are many parties to blame for the bug but it's pretty niche since monodevelop is probably abandoned for good today. I have no idea how I got it installed in the first place, I never developed for .NET. Maybe it was pulled as a dependency even though it doesn't exist in the current Debian package archives. So I think leaving everything as is would be good and if it happens to someone else we can simply link them this issue. Thanks for you help! |
Fixes BitBoxSwiss#2684 and hopefully BitBoxSwiss#3061. Without this, on linux the local mimetype database (influenced by various packages installed on the system) can mess with the mimetype resolution of our .html/.js/.css files served locally, resulting in a blank page. This manually intercepts local requests and forces mimetype resolution by filename extension only, to avoid the system mimetype database from breaking the app.
Fixes BitBoxSwiss#2684 and hopefully BitBoxSwiss#3061. Without this, on linux the local mimetype database (influenced by various packages installed on the system) can mess with the mimetype resolution of our .html/.js/.css files served locally, resulting in a blank page. This manually intercepts local requests and forces mimetype resolution by filename extension only, to avoid the system mimetype database from breaking the app.
Fixes BitBoxSwiss#2684 and hopefully BitBoxSwiss#3061. Without this, on linux the local mimetype database (influenced by various packages installed on the system) can mess with the mimetype resolution of our .html/.js/.css files served locally, resulting in a blank page. This manually intercepts local requests and forces mimetype resolution by filename extension only, to avoid the system mimetype database from breaking the app.
Fixes BitBoxSwiss#2684 and hopefully BitBoxSwiss#3061. Without this, on linux the local mimetype database (influenced by various packages installed on the system) can mess with the mimetype resolution of our .html/.js/.css files served locally, resulting in a blank page. This manually intercepts local requests and forces the correct mimetype for a set of hardcoded extensions.
Fix released in v4.46.2 (as part of fixing a more critical version of the same issue in #3061). |
Only a dark empty window is shown but nothing in it. There are no errors in the log either. Might be the same issue as #2618, I tried both .deb and .AppImage, same symptoms. The app itself seems to work as there's a password prompt on my BitBox02, and when I enter it the device unlocks, there's also some activity in the log after that as well. I downgraded the app (.deb) to 4.41.0 and it works fine again.
I use Debian testing, NVIDIA RTX 3090 Ti if hardware is related. There was a recent Chromium bug in Steam that caused similar issues, the main window is empty. Turning hardware acceleration off helps but it seems this program already uses software rendering. I tried setting
BITBOXAPP_RENDER=auto
as said in the docs but it didn't help.Part of the log:
The text was updated successfully, but these errors were encountered: