Popup can't be closed in several scenarios, under Cinnamon DE

[ldx63]

Relevant components

• Standalone tray application (based on Qt Widgets)
• Plasmoid/applet for Plasma desktop
• Dolphin integration
• Command line tool (syncthingctl)
• Integrated Syncthing instance (libsyncthing)
• Backend libraries

Environment and versions

• Versions of syncthingtray, qtutilities and c++utilities: 1.6.2-1.97bcea6 (flatpak), (unknown), (unknown)
• Qt version: 6.7.3
• C++ compiler (name and version): N/A
• C++ standard library (name and version): N/A
• Operating system (name and version): Fedora 40 - Cinnamon 6.2.9

Bug description
Under Cinnamon 6.2.9 (Fedora 40), once I click on the tray icon, the popup appears correctly. The problem is that the popup can't be dismissed easily: the only way to dismiss it is by clicking on a certain white area. In the meanwhile, no other element of the desktop can be used, not even the desktop itself.
I tried to modify "Window type" in Settings/Appearance, something changes but the problem persists.
I think that an easy solution for this issue is to add a "Close" pushbutton somewhere in the popup.

Steps to reproduce

1. Click tray icon
2. Click elsewhere

Expected behavior
The popup should close when clicking elsewhere - but the desktop and other windows can not be used until the popup is closed by pushing ESC key or clicking on a very specific white area.

Screenshots
I made a short video that explains what happens:
https://drive.google.com/file/d/1mKqwmAlJ6VJC9EaZVagYIICJNyay-wQC/view?usp=sharing

Additional context
N/A

--

Thank you and keep up the good work.
Aldo

[Martchus]

Are you using X11 or Wayland? Normally it is possible to dismiss the popup by clicking at some point outside of the window. I believe when I tested this under Cinnamon/X11 not that long ago it worked as expected.

Nevertheless, this sounds more like a platform limitation. I can think of adding some workaround but that would be a feature request.

[ldx63]

Hi Martchus, thank you for your answer.

I'm using X11.
No, clicking outside the popup has no effect, as showed in the video I posted.

Note: I tried syncthingtray quite a long time ago (at least last year or even before) under Cinnamon in Linux Mint, and I am quite sure that I got exactly the same behaviour: that was the reason why I stopped using it.

Anyhow, I agree that this could be a feature request.

Thank you again
Aldo

[Martchus]

I've just tested this under Openbox/X11 and KDE/Wayland and cannot reproduce the problem. I can test it later under Cinnamon/X11 when I'm on my other system.

Did you set the environment variable QT_XCB_NO_GRAB_SERVER by any chance? Since closing a popup by clicking on a random place outside the popup window itself relies on grabbing the mouse under X11 this environment variable must not be set. However, considering you also cannot focus the other window it is probably not that.

Considering the statistics are still updating the Syncthing Tray UI is also not completely unresponsive. Can you close the popup by pressing the ESC key?

Note that if you set the window type to "Normal window" this behavior is actually expected because normal windows are not supposed to close when clicking somewhere else. It is weird that you don't get a normal window frame when selecting "Normal window", though. So something is off in your case - like the window manager does not really honor the window flags set by Syncthing Tray. This definitely works under KDE/Wayland and KDE/X11 and Openbox/X11 so I doubt it is an issue of Syncthing Tray itself.

I was already using Qt 6.8.0 for all my tests but I don't think it makes a difference.

[ldx63]

Hi,
QT_XCB_NO_GRAB_SERVER is not set.
Yes, I can close the popup by pressing ESC.
I agree with your diagnosis, the WM is doing something wrong/unexpected by STtray.
Maybe some "integration" library that is missing on my PC, but I don't think so, since I installed the Flatpak version.

Now I've just tried to uninstall the Flatpak version and try the packaged binary version for Fedora 40 from https://software.opensuse.org/download.html?project=home:mkittler&package=syncthingtray but I got exactly the same behaviour. In this case syncthingtray is 1.6.2 using QT 5.15.15.

Kind regards
Aldo

[Martchus]

Maybe some "integration" library that is missing on my PC

Normally no additional library is required for this. To be 100 % sure you could try the binary from the website which definitely bundles everything (that can be reasonably bundled).

Yes, I can close the popup by pressing ESC.

Good. I suppose that can serve as a workaround and it means that this is really about the input handling itself (and not that the popup was unable to process close events at all).

It makes probably sense to use the dedicated packaging I have for Fedora. It is useful that you've tested it with Qt 5 as well but I suggest you install the Qt 6 based version instead (https://software.opensuse.org/download.html?project=home:mkittler&package=syncthingtray-qt6).

[ldx63]

I suggest you install the Qt 6 based version instead (https://software.opensuse.org/download.html?project=home:mkittler&package=syncthingtray-qt6).

I just installed this package on a different machine with same version of OS and DE, but I confirm exactly the same behaviour.

Kind regards
Aldo

[Martchus]

I couldn't reproduce the issue on my Cinnamon/X11 setup under Arch Linux (which also is at Cinnamon version 6.2.9 at the moment). I tested with my native Arch Linux packaging and the Flatpak packaging of the newly released Syncthing Tray version.

I could only reproduce the missing window decorations for the normal window and noticed that the window is not resizable by dragging the edges. (I suppose the window not being resizable is a limitation under X11 in general and probably not that bad considering one can also configure the size in the settings.)

[Martchus]

And are you sure you're not using Wayland? I wanted to cross-check this on my side but on my system the Cinnamon/Wayland session just gives me a black screen.

[ldx63]

I am sure that I am using X11, as confirmed by the echo $XDG_SESSION_TYPE command.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.