Open RedTopper opened 1 month ago
every machine should have the same configuration
..no? Flatpak doesn't have this guarantee, it makes apps have the same configuration on many machines, but Vesktop, like many other apps, still relies on the resources the host system provides to work properly.
If this is related to how the Flatpak is packaged, you're going to need to provide a lot more information on how your system is configured. Are you using ibus like the OP? Are you using something else? Does this work fine with the rpm package? etc.
..no? Flatpak doesn't have this guarantee, it makes apps have the same configuration on many machines, but Vesktop, like many other apps, still relies on the resources the host system provides to work properly.
Hi, yes, sorry, different machine configurations but similar app configuration. So let me answer your follow up questions and see what I can find.
I am using ibus set to English. Running ibus exit
from a console seems to avoid the crash.
Running the AppImage directly on the host with ibus running without any extra arguments runs OK and I can select chats.
Running on the host with the following arguments causes a crash:
./Vesktop-1.5.3.AppImage --enable-speech-dispatcher --disable-gpu-sandbox --ozone-platform-hint=auto --enable-wayland-ime
Checking for update
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] listening on 6463
[arRPC > process] started
Update for version 1.5.3 is not available (latest version: 1.5.3, downgrade is disallowed).
checkForUpdatesAndNotify called, downloadPromise is null
[1] 15204 illegal hardware instruction (core dumped) ./Vesktop-1.5.3.AppImage --enable-speech-dispatcher --disable-gpu-sandbox
And finally removing the --enable-wayland-ime
argument from the AppImage causes it to work again, but obviously disables the ability to input any other language supported by ibus.
As another workaround for now I can kill ibus, since I don't really want to disable Wayland support, since startvesktop
enforces that flag when wayland is supported.
From what you've told me, it looks like this might be an issue with Chromium/Electron or ibus, rather than Vesktop or the Flatpak specifically. Unfortunately dropping the IME flag in our scripts isn't an acceptable solution since people depend on it.
Does the issue occur with fcitx5, if you're able to try it? If it doesn't, I'm going to chalk it up to ibus doing something funky that C/E doesn't like.
Just installed/layered fcitx5 on my current deployment and I can use Japanese input on that just fine, and switching back to ibus through KDE's Keyboard -> Virtual Keyboard setting immediately caused a crash so yes, I'm inclined to agree that this is a weird ibus issue interacting with Electron and the flag should not be dropped.
Sounds like the root cause is found now. It could be useful to have an environment variable that skips adding the --enable-wayland-ime
flag in startvesktop
as an additional workaround so I can still use ibus in applications like Firefox, but since this is an upstream issue I'll let you decide.
It's at least good to have this issue documented here so other ibus users facing the same issue have workarounds.
Thanks!
Edit: Ah, #34 explains why I started seeing this about a week ago. Adding this comment to tag that PR as related. Edit 2: Also related: https://github.com/Vencord/Vesktop/issues/894
It seems that there is a related merge in the Chromium 127 cycle. Merge: https://chromium-review.googlesource.com/c/chromium/src/+/5598518 Version found from https://chromiumdash.appspot.com/commit/715fcc5676f373ac953c468f60434a5f4b0c0fe6 Discussion: https://issues.chromium.org/issues/40263583
And yes this does only happen on the very combination of IBus + KDE + Wayland...
I did a little more digging from Linus's comment. The patch containing the fix is included starting Chromium 128, and the current Electron stable release is at Chromium 130. Updating to that release should (in theory) solve our issues. (I also posted this on the Vesktop issue, as this would be on them to update AFAIK).
For what it's worth, we're one and the same people, Flatpak is an official distribution and therefore has first-party support :p
Vesktop has a bit of a slow release cycle since we don't want to constantly push tons of updates (it annoys users a ton) and since this is only in a specific system configuration it's not the most high priority issue in the world. Nevertheless, we are already bumping Electron for this upcoming release anyway, which will resolve the issues.
Thank you everyone for the help, and I'm glad we were able to hunt down the issue. It sucks that it's a single system config that causes this because it's such a pain to debug...
I'll close this issue when the new version is pushed to Flathub.
Hey!
I've noticed that recently I cannot access any chat UI on discord, though the main page and settings still works. The behavior is exactly the same as what is shown in the video for this issue here:
https://github.com/Vencord/Vesktop/issues/903
Upstream closed the above issue citing that it may be a system issue, but due to the nature of Flatpak every machine should have the same configuration, so it may be due to the way this application is packaged?
Starting the Flatpak version via the terminal leads to the following error message after clicking on a chat:
Workarounds
New: Kill ibus
Using Flatseal to disable Wayland support will prevent Vesktop from crashing.
I am currently using the official Discord flatpak for the time being.System Information