Created attachment 127839 [details] screenshot SUMMARY I'm not sure if this is the right place to report this issue. If not, re-assign please. Qt apps installed via flatpak show "Background activity" notification when running for a while, ~2 minutes. Such notification not always appears, but the steps below are enough most time. STEPS TO REPRODUCE 1. install some Qt app via flatpak/flathub (kdenlive, kolourpaint and openshot shown the mentioned notification on my system) 2. open the installed app and minimize it 3. OBSERVED RESULT some time later, generally ~2 minutes, the "Background activity" notification appears and remains on the screen until we close it manually. See the attached screenshot please. EXPECTED RESULT apparently it's a useless notification, it should not appear SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2
I cannot reproduce this (tested with org.kde.kdenlive)! Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8
The background portal (the one responsible for this) is part of upcoming Plasma 5.19, which means you can get it only from git master as of now. Patrick, is it possible that you restart xdg-desktop-portal-kde with some flatpak application running? I was able to reproduce it sometimes, but I'm not sure yet why it's happening, it's some miscommunication with xdg-desktop-portal-kde and xdg-desktop-portal. I will keep investigating.
Created attachment 127885 [details] screenshot taken on Neon unstable (In reply to Jan Grulich from comment #2) > Patrick, is it possible that you restart xdg-desktop-portal-kde with some > flatpak application running? I not even know how to do it. As we can see in the attached screenshot, the issue reported here also occurs on Neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.18.80 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.1
Patrick, is this on Wayland?
This behavior occurs on both X11 and Wayland sessions.
It should be fixed in Plasma 5.19.
yesterday I saw the same notification on Plasma 5.19 beta.
one more Plasma 5.19 beta user affected: bug 421959
It's not fixed in the beta, it will be fixed in the stable release.
Created attachment 129329 [details] screenshot of Plasma 5.19 Currently it's harder to reproduce, but it's still happening. Operating System: Arch Linux KDE Plasma Version: 5.19.0 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0
Is this on Wayland?
(In reply to Jan Grulich from comment #11) > Is this on Wayland? yes
Created attachment 130247 [details] notification triggered by Transmission (GTK3) Humm, as we can see in the attached screenshot, GTK3 app (Transmission in this case) also triggers the notification on Wayland session. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.73.0 Qt Version: 5.14.2
I can see this notification every now and then, even when the application is still open with no apparent reason. I'm not sure how it's supposed to work.
I think what's going on. It works that way that the xdg-desktop-portal-kde reports a list of opened apps on the Plasma session, while xdg-desktop-portal tracks all Flatpak apps and if some of the apps is not reported by xdp-kde, then a notification appears informing the user that an app runs in the background, as it's something user probably doesn't know even if the xdp-kde doesn't know about it. In this case I believe it's triggered by apps which are only minimized in the system tray. I will try to investigate how to get information about these.
I was trying to fix this, but I don't know how to get appstream IDs of applications running in the system tray. I can list them through StatusNotifierHost interface on DBUs, but the ID is different (e.g. Konversation vs org.kde.Konversation). If I want to get the PID of the process which registered SNI, then I get PID of xdg-dbus-proxy so that doesn't help either. In GNOME this is not a problem as they don't support system tray. Any idea?
It persists with Plasma 5.20 beta. Apparently it's not a kde software issue, I already saw this notification on Gnome too. Operating System: Arch Linux KDE Plasma Version: 5.19.90 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1
Can reproduce with openshot from flathub. https://flathub.org/apps/details/org.openshot.OpenShot Flatpak 1.12.4 Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Graphics Platform: Wayland
I'm also able to reproduce this with LibreOffice 7 KDE Neon stable. I need help on how to revoke it after clicking Find out more, I am not able to change the permission back to normal. Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-37-generic (64-bit) Graphics Platform: Wayland
(In reply to fil7racket from comment #19) > I'm also able to reproduce this with LibreOffice 7 KDE Neon stable. > I need help on how to revoke it after clicking Find out more, I am not able > to change the permission back to normal. Flatseal can do that.
This happens every time I launch Discord or Bottles, both of which are installed via Flatpak. This notification needs a timeout, I shouldn't have to click on the little X every single day. Or I just need to be able to whitelist certain apps, or just disable that "in the background" notification entirely (currently it's all "something happened in the app" notifications or nothing)
https://www.reddit.com/r/kde/comments/11ul75n/comment/jcrlzdu/?utm_source=share&utm_medium=web2x&context=3 > I once had this popup on one of my applications packaged as Flatpak as well. > From my testing on KDE it seems to get triggered when an application - launched as Flatpak loses focus and / or has a tray icon - doesn't implement the xdg background portal. > As for my app, I implemented xdg background portal using libportal and that popup went away. This indeed seems to happen on an individual app basis. Telegram and KSnip work correctly and only trigger the notification when they're *closed* to the tray. Other apps do not work correctly. Additionally, this bug can lead to destructive behavior that I found out in the MicroOS Desktop channel: Firefox triggers this notification, and if the user clicks on Learn More and then select the option to stop it from running in the background, Firefox simply closes, and every time it gets opened again, it's immediately closed. The only way to revert the operation is by using Flatseal, going to the app's Portal settings and either clicking the cleanup/undo icon or allowing the app to run in the background. The Flatpak KCM lacks these settings, last I saw. So this is hard for users to find out, and if they cannot find this, they become incapable of reopening the application.
> user clicks on Learn More and then select the option to stop it from running in the background, Firefox simply closes, and every time it gets opened again, it's immediately closed. Can confirm this behavior for the flatpak app `localsend`. > The only way to revert the operation is by using Flatseal, going to the app's Portal settings and either clicking the cleanup/undo icon or allowing the app to run in the background. The Flatpak KCM lacks these settings, last I saw. So this is hard for users to find out, and if they cannot find this, they become incapable of reopening the application. Can also confirm that. This is tracked with bug #466325.
This bug report has morphed over time in a somewhat confusing matter. Let's use it to track the issue of the app asking for background permission every single time it runs, rather than remembering the prior setting. Patrick, can you still reproduce that?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!