Open tdug opened 2 months ago
I've verified this bug does not occur when using i3 Desktop. This is the only other alternative desktop environment I have installed on this machine.
I was able to trigger this as well (Gnome 46 on Debian Sid). It happens if there is an extension that enables System Tray, such as https://extensions.gnome.org/extension/615/appindicator-support/ or https://extensions.gnome.org/extension/2890/tray-icons-reloaded/.
If such an extension is enabled, and a Juce App tries to use the System Tray, it will crash the Desktop Session.
In my case (see discussion on https://github.com/kushview/element/issues/820), I had the following error in the log:
Received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 9958 error_code 3 request_code 2 (core protocol) minor_code 0)
(serial would change).
I can reproduce the issue in the DemoRunner on Ubuntu 24.04.1 LTS with the default Wayland session. In the "Logs" app I also see a BadWindow "invalid window parameter" error at the point of the window system crash.
The cause of the issue isn't clear to me yet. If I comment out the following line, then the DemoRunner will launch and run as expected, though without any system tray icon:
Given the error message in the logs, maybe the systemtray-manager window is invalid (unlikely, given that we just queried it), or the JUCE icon window is invalid. I'm pretty sure the JUCE window exists at this point, so I guess this would indicate some kind of configuration issue. It's also possible that the error is elsewhere. As far as I can tell, the X11 error handler in the JUCE app never fires, so I'm not convinced that the X11 error is generated by the JUCE app at all. As far as I can tell, the system tray works by using Xembed to embed the JUCE icon window into a separate parent window, so the error might be coming from the parent window.
I don't think it should be possible to crash the session just by sending a message with a bad window parameter. Even if the tray icon doesn't show, I'd expect the desktop session to keep running. So, I feel confident that there is some kind of bug in Gnome or Xwayland. Even if the JUCE app is doing the wrong thing somehow, the desktop session shouldn't die.
Just for the record: I can reproduce the issue on manjaro with GNOME Shell 46.5 and AppIndicator and KStatusNotifierItem support extension enabled.
journalctl gives the following:
... Okt 25 19:24:36 manjarobox gnome-shell[5307]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x280000a Okt 25 19:24:36 manjarobox gnome-shell[5307]: Received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 25188 error_code 3 request_code 2 (core protocol) minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the MUTTER_SYNC environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the mtk_x_error() function.) Okt 25 19:24:36 manjarobox gnome-shell[5307]: == Stack trace for context 0x564a4c8bf790 == Okt 25 19:24:36 manjarobox gnome-shell[5307]: #0 564a4c9a9898 i resource:///org/gnome/shell/ui/init.js:21 (e69bb370bf0 @ 48) ...
After disabling the AppIndicator and KStatusNotifierItem support extension, the DemoRunner app does not crash the gnome-shell anymore. I described my issue on the JUCE forum here.
But now the SystemTrayIcon of the DemoRunner app is shown in the upper left corner of my desktop:
I want to mention, that I am NOT on Wayland, but X11 session!
Hi @reuk,
I've created an issue on the gnome-session project here.
What is the current state of affairs here?
I think there are problems on both sides. JUCE is probably doing something wrong in order to trigger the faulty behaviour in the first place, but I think the desktop session should be more resilient so that it doesn't completely crash as a result.
Unfortunately it's quite difficult and time-consuming for us to debug the issue on our side when the desktop session goes away, so it's not a great use of time given that we have other issues of a higher severity to address. I'm planning to revisit this once the crash is fixed in the desktop session, or once I run out of other issues of higher/similar severity to investigate.
Detailed steps on how to reproduce the bug
What is the expected behaviour?
SystemTrayIconComponent loads
Operating systems
Linux
What versions of the operating systems?
Ubuntu 24.04 [Default Desktop]
Architectures
x86_64, 64-bit
Stacktrace
Plug-in formats (if applicable)
Standalone
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the
develop
branchThe bug is present on the
develop
branchCode of Conduct