Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: System tray icons (such as volumeicon, nm-applet, slack, redshift-gtk...) disappear when reloading i3's config or changing monitor settings (by using arandr for instance). Version-Release number of selected component (if applicable): i3-4.18.2-1.fc32.x86_64 How reproducible: Always on some specific applications. Steps to Reproduce: 1. Start an application with a tray icon (such as volumeicon or redshift-gtk) within an i3 session 2. Reload the i3 config: $mod+Shift+r 3. Observe that the icons disappear Actual results: The tray icons disappear. Expected results: The tray icons should be kept alive. Additional info: It seems that the bug is coming from a wrongly applied patch in i3 upstream 4.18.2: https://github.com/i3/i3/issues/4159 Cherry-picking this specific patch would help on that specific issue: https://github.com/i3/i3/commit/838b600fead202416013db5c1b57f7031f06bed6 i3-4.18-1.fc32.x86_64 does not seem to suffer from that issue.
I cannot reproduce this bug, do you have a special setup like multiple monitors or a compositor?
Created attachment 1712737 [details] Recording of the issue Here is a video recording of the issue I am facing. I am basically starting the tray icon app "volumeicon". After calling "i3-msg restart", the app crashes and the tray icon disappears. Here is the error message the app yields: (volumeicon:131539): Gdk-WARNING **: 22:33:52.398: GdkWindow 0x1a00002 unexpectedly destroyed (volumeicon:131539): Gdk-ERROR **: 22:33:52.418: The program 'volumeicon' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 909 error_code 141 request_code 138 (RENDER) minor_code 7) (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 GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [1] 131539 trace trap (core dumped) volumeicon
To answer your question concerning monitors and compositors: I can reproduce the issue with a single monitor, and I do not have any compositor. Thanks a lot for looking into that issue, Jean
Could you grab i3 from koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=50209934 and try if that fixes the issue for you?
(In reply to Jean Guegant from comment #2) > Created attachment 1712737 [details] > Recording of the issue > > Here is a video recording of the issue I am facing. > I am basically starting the tray icon app "volumeicon". > After calling "i3-msg restart", the app crashes and the tray icon disappears. > Here is the error message the app yields: > > > (volumeicon:131539): Gdk-WARNING **: 22:33:52.398: GdkWindow 0x1a00002 > unexpectedly destroyed > > (volumeicon:131539): Gdk-ERROR **: 22:33:52.418: The program 'volumeicon' > received an X Window System error. > This probably reflects a bug in the program. > The error was 'RenderBadPicture (invalid Picture parameter)'. > (Details: serial 909 error_code 141 request_code 138 (RENDER) minor_code 7) > (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 GDK_SYNCHRONIZE environment > variable to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > [1] 131539 trace trap (core dumped) volumeicon Interesting, the issue neither appeared with kdeconnect-indicator nor with Telegram, but I can reproduce it with volumeicon. The patch that you linked fixed the issue for me. I'll submit a fix shortly.
I upgraded to i3-4.18.2-2.fc32.x86_64 in the Koji above, but nm-applet and blueman applets still do not appear for me. I am wondering if this is an i3/X11 issue, or if it is a code difference of how these specific applets appear in the system tray. Does anyone know when the regression was first noticed? I am trying to think which part might have moved to break the tray icons.
FEDORA-2020-bc566903ff has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bc566903ff
(In reply to Justin W. Flory (he/him) from comment #6) > I upgraded to i3-4.18.2-2.fc32.x86_64 in the Koji above, but nm-applet and > blueman applets still do not appear for me. I am wondering if this is an > i3/X11 issue, or if it is a code difference of how these specific applets > appear in the system tray. > > Does anyone know when the regression was first noticed? I am trying to think > which part might have moved to break the tray icons. nm-applet works for me, it just takes a while for it's icon to render for some reason. But once it's there, it survives the reload of i3.
FEDORA-2020-47ea92ef6b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-47ea92ef6b
FEDORA-2020-439e9821cf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-439e9821cf
I tested the rpm package from the koji. It works like a charm, even with reloading. Thanks a lot, Jean
Please test the bodhi updates (and give them karma) once they hit testing as well if you can ;-)
I left karma on the Bodhi update. I had to do a full reboot to notice the change, but now my systray (and compose key somehow!) are working again. Thanks Dan for getting this fixed up for us in Fedora! \o/
FEDORA-2020-bc566903ff has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-439e9821cf has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-439e9821cf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-439e9821cf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-47ea92ef6b has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-47ea92ef6b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-47ea92ef6b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-439e9821cf has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-47ea92ef6b has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-20f42bd6f3 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-20f42bd6f3
FEDORA-2020-20f42bd6f3 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-20f42bd6f3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-20f42bd6f3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-20f42bd6f3 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.