SpacingBat3 / WebCord

A Discord and SpaceBar :electron:-based client implemented without Discord API.
MIT License
1.92k stars 95 forks source link

Maximizing "accept invitation" window crashes the whole program #540

Open Stehlampe2020 opened 4 months ago

Stehlampe2020 commented 4 months ago

Acknowledgements

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

30.0.2

Application version

4.9.1

Bug description

When I click on a Discord invite link in my browser (in this case Firefox Developer Edition 126.0b9) it shows the "Your Discord app has been opened" screen in the browser and the "Accept invite" window automatically pops open in WebCord (which it doesn't do on the official Discord client which I also have installed, so that's a plus for WebCord!). Maximizing that window completely closes WebCord (including the background process that runs when I just close the WebCord window).

Additional context

Notice: This issue was automatically generated by WebCord.

(webcord:29755): LIBDBUSMENU-GLIB-WARNING **: 23:47:16.108: About to Show called on an item wihtout submenus. We're ignoring it.

(webcord:29755): LIBDBUSMENU-GLIB-WARNING **: 23:47:16.112: About to Show called on an item wihtout submenus. We're ignoring it. Segmenteringsfel (minnesutskrift skapad)


When setting my core dump pattern to be able to capture the core dump that the log mentions ("minnesutskrift skapad"→"memory dump created") to a file instead of a pipe to `/usr/bin/apport` the crash became "unreliable", i.e. not occurring every time I maximized the window. Here's the crash dump, though: https://drive.google.com/file/d/18Wq6iM_EZeX9ef3fOMkJ7VXoRRTubqEU/view?usp=sharing (GitHub didn't like the file type and it would be way too large anyway)   
SpacingBat3 commented 4 months ago

Resizing the window doesn't crash, but opening it in a tiling window manager like e.g. Hyprland might.

It doesn't crash for me on XFCE4+Nouveau (with XFWM4, which is floating window manager) everything works as it should be (no crash, maximize works fine). I see you could reproduce this on KDE/Wayland (I suppose?); which package are you using to run WebCord and does it tweak OZONE to launch WebCord within Wayland as opposed to Chromium defaults (i.e. most likely XWayland)? Also, can you reproduce this with X11 DE (check this on something else than XWayland)?

You might try checking how it works with Wayland if you're at XWayland and the opposite way.

SpacingBat3 commented 4 months ago

(...) which it doesn't do on the official Discord client which I also have installed, so that's a plus for WebCord! (...)

That could actually be due to WebCord starting its own WebSocket server at the same port as Discord, overriding it (meaning browsers might not access Discord if WebCord's running). You might try starting Discord first and waiting for it to fully load, then starting WebCord in order to have Discord reserve port number before WebCord (or just avoid running Discord in general when WebCord's already running).

Stehlampe2020 commented 4 months ago

That could actually be due to WebCord starting its own WebSocket server

Before I had WebCord installed and discord-canary from Discord's official deb file was running in the background basically whenever my computer was turned on it didn't open the invite window either.

Stehlampe2020 commented 4 months ago

which package are you using to run WebCord

I'm using the […]amd64.deb from the releases/latest page of this repo.

does it tweak OZONE to launch WebCord within Wayland as opposed to Chromium defaults (i.e. most likely XWayland)?

I have absolutely no clue. I just installed the package as stated above and ran it.

You might try checking how it works with Wayland if you're at XWayland and the opposite way.

How do I see how the internal Chromium instance is launched? I think it should run in Wayland directly, but I don't know what Electron version you use and if that required XWayland to run.

I see you could reproduce this on KDE/Wayland (I suppose?);

Well, the bug stopped reliably happening; as soon as I changed my /proc/sys/kernel/core_pattern to capture the core dump to a file instead of a pipe to apport the bug became unreliable and now only happens sometimes.