Created attachment 171904 [details] screenshot SUMMARY I can reproduce this bug on my system with jdownloader (java app), tv-browser (java app) and uGet download manager (gtk app). STEPS TO REPRODUCE 1. run any affected app mentioned above 2. left/right click on the tray icon of the app 3. OBSERVED RESULT the dialog seen in the attached screenshot shows up EXPECTED RESULT remote control should not be requested after the provided steps SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Graphics Platform: Wayland
BiglyBT torrent client (java app) is also affected.
What happens is this: These applications use legacy xembed tray icons. Our xembedsniproxy uses XTest to send events to the application. Since recently XWayland translates XTest requests to remote desktop portal requests, triggering the prompt
Im also seeing the dialog with game controllers. I have one connected via a 2.4ghz usb adapter and bluetooth, both prompt this dialog box to popup. not sure if its exactly the same issue then but I keep getting this same dialog coming up and it only started doing this maybe a few weeks ago. If I click cancel, it'll popup again when I send any kind of input from the controller (any button, stick movement, trackpad input). If I hit "share" it has a like a 1/3 chance to completely lock up the display and I need to force reboot (cant get to any tty) the controller will continue to be detected and work through kde but steam (and I suspect the games) wont be able to take the inputs unless I hit share.
I'm encountering the same issue, while using Wireguird & JDownloader2 (GTK apps). What I've also noticed is that once the access is given, clicking it will not sent the click event to the app, instead the tray item will be stuck in clicked action. And if I hover over an item which supports clicking/activating, it sends the click to that one. And randomly & very rarely, I can actually get the mouse action to go through. I can't reproduce how, so far.
I have the same issue when issue when using my Playstation 4 controller: https://bugs.kde.org/show_bug.cgi?id=490509
It first started happening to me when I used Steam remote play with my Linux machine as the host. I use Fedora 40 KDE, Wayland. I have a Dualsense controller, using it via Bluetooth never triggers it.
>. Our xembedsniproxy uses XTest to send events to the application Just to clarify that, we have two paths. One uses xtest one does not. The xtest path is more of a hack, at the time for just GTK3. If anyone can test commenting out: plasma-workspace/xembedsniproxy/sniproxy.cpp ``` if (windowAttributes && !(windowAttributes->all_event_masks & XCB_EVENT_MASK_BUTTON_PRESS)) { m_injectMode = XTest; } ``` and see if clicking their app still works that would be useful. We can try and make the xtest path less used.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4565
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/303
Git commit 4f82c43d4091abbd36a4e446d887344677e32d6a by David Redondo. Committed on 29/07/2024 at 10:50. Pushed by davidre into branch 'master'. remotedesktop: Only show the restore checkbox if the app wants to persist Otherwise it promises to do something that will not happen. M +1 -0 src/RemoteDesktopDialog.qml M +1 -1 src/remotedesktop.cpp M +2 -1 src/remotedesktopdialog.cpp M +2 -1 src/remotedesktopdialog.h https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/4f82c43d4091abbd36a4e446d887344677e32d6a
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/304
Git commit 2fa4cb52313b8a4d91d3525b398f7419d96ce9c6 by David Redondo. Committed on 29/07/2024 at 11:35. Pushed by davidre into branch 'Plasma/6.1'. remotedesktop: Only show the restore checkbox if the app wants to persist Otherwise it promises to do something that will not happen. (cherry picked from commit 4f82c43d4091abbd36a4e446d887344677e32d6a) Co-authored-by: David Redondo <kde@david-redondo.de> M +1 -0 src/RemoteDesktopDialog.qml M +1 -1 src/remotedesktop.cpp M +2 -1 src/remotedesktopdialog.cpp M +2 -1 src/remotedesktopdialog.h https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/2fa4cb52313b8a4d91d3525b398f7419d96ce9c6
Git commit b0f3f954021280bfe21d4f36bec0279620c860cd by David Redondo. Committed on 29/07/2024 at 12:29. Pushed by davidre into branch 'master'. xembed-sni-proxy: Check if descendant windows want button events This notably fixes some Java apps where the embedded window is not intrested in button events but a child is. M +19 -1 xembed-sni-proxy/sniproxy.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/b0f3f954021280bfe21d4f36bec0279620c860cd
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4566
Git commit bf145579129e363cf14064bb369260c303b9ae23 by David Redondo. Committed on 29/07/2024 at 14:16. Pushed by davidre into branch 'Plasma/6.1'. xembed-sni-proxy: Check if descendant windows want button events This notably fixes some Java apps where the embedded window is not intrested in button events but a child is. (cherry picked from commit b0f3f954021280bfe21d4f36bec0279620c860cd) Co-authored-by: David Redondo <kde@david-redondo.de> M +19 -1 xembed-sni-proxy/sniproxy.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/bf145579129e363cf14064bb369260c303b9ae23
I'm still seeing this issue as well as broken clicks on icons in GTK apps. I use ibus-ui-gtk3 as an IME which I use because I prefer it over Fcitx. I keep hoping KDE will one day add iBus support of its own with a Plasmoid and candidate selection menu that's Breeze themed and integrates well with the desktop. I think that's what kimpanel is supposed to do but I've never got it to work as well as ibus-ui-gtk3, maybe I'm doing something wrong?. Anyway, long story short the ibus-ui-gtk3 systray is completely broken with xembed-sni-proxy, it used to work fine though. I found a really good workaround in Stalonetray: https://wiki.archlinux.org/title/Stalonetray Amazingly, this just works and implements a standalone systray for Xembed apps with none of the limitations of xembed-sni-proxy. I use the following command to launch it which places it at the top of my second display and allows windows to cover it: stalonetray --window-type normal --window-layer normal --background '#2d3134' --geometry 10x1+3840-1600
Git commit 0dcc0e40f947594d4b59b4d2d57461a5ea31f9c1 by David Edmundson. Committed on 02/10/2024 at 22:11. Pushed by davidedmundson into branch 'master'. xembedsniproxy: Leave real window active during event dispatch With the new libei integration a click on an xmebedsiproxy item that uses xtest there is a roundtrip through kwin and back. We need to then put a delay so the window remains until that hits. Tested with Skype M +14 -1 xembed-sni-proxy/sniproxy.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/0dcc0e40f947594d4b59b4d2d57461a5ea31f9c1
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4782
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4783
Git commit bb71b6257f89d29b90008e3c4df62094fe2446d9 by David Edmundson, on behalf of David Edmundson. Committed on 02/10/2024 at 22:28. Pushed by davidedmundson into branch 'Plasma/6.2'. xembedsniproxy: Leave real window active during event dispatch With the new libei integration a click on an xmebedsiproxy item that uses xtest there is a roundtrip through kwin and back. We need to then put a delay so the window remains until that hits. Tested with Skype (cherry picked from commit 0dcc0e40f947594d4b59b4d2d57461a5ea31f9c1) 29665403 xembedsniproxy: Leave real window active during event dispatch Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +14 -1 xembed-sni-proxy/sniproxy.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/bb71b6257f89d29b90008e3c4df62094fe2446d9
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5383
Created attachment 181201 [details] screenshot taken on neon unstable On neon unstable, remote control is requested after every login. Operating System: KDE neon Unstable Edition KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.0 Graphics Platform: Wayland
This bug should probably have its severity risen, having it as normal is misleading. IMHO, issues that impact security related features should be given a high priority, and the "remote control requested" *is* an important security feature. Creating the premises so that the users *learn to disregard* dialogs asking for permissions to be granted and allow permissions by default since the dialog appears spuriously should be regarded as a security problem. It is probably a fortunate (rather than unfortunate) coincidence that even when users allow the permission the system tray icon does not work anyway, otherwise many users would now take for granted that permission requests from systray icons must *always* be allowed because of bugs. A few questions: 1. Is there the possibility for the xembedsniproxy to do something else rather than using XTest to propagate events to the applications? From the comments below, this seems to be the case. 2. Apparently this issue is specific to plasma, how do other DEs deal with the problem? Using something else rather than XTest? 3. If the XTest mechanism is the only possible one, then the problem is clearly with XWayland. Has a bug been opened for it? Can it be tracked here?
The dialog was kind of misleading, yeah; "remote control" implies someone somewhere else trying to take over your computer. What's actually going on is that the app you clicked on is asking to be able to look at the screen and control the input devices. The dialog was clarified to make this much more obvious recently in https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/ccf1e33a04abd53d58aa3f4d5ea694a4116fab69.
Created attachment 187460 [details] attachment-3531232-0.html Hi, improving the message helps! The fundamental problem remains, though: to make a system tray icon work, you need to grant a permission to read the screen. This teaches users that to have “fundamental” functionality you need to grant apps permissions to read the screen, which may lead to users granting that permission to malicious apps too without thinking. Real solution would be to have electron apps being able to use the systray on plasma without the need for special permissions to read the whole screen. In this respect, it is unclear to me if the issue is with electron, plasma or both. Surely, applications using older versions of the electron framework use the systray without asking for special permissions (e.g., sleek 0.20). Apps using more recent versions of the framework do (e.g.sleek 0.22). Another even more fundamental problem is that once granted the permission, no-one knows how to revoke it or where it is stored. Until no long ago, I could see the permission with |flatpak permissions|, now I cannot anymore. Furthermore, the permissions entry of the kde system settings is grayed out. Finally, the permission is not in any of the locations suggested by chatgpt. Info on the last point would be great to have. Best regards, Sergio On 02/12/2025 05:15, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=490666 > > Nate Graham<nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Latest Commit| |https://invent.kde.org/plas > | |ma/xdg-desktop-portal-kde/- > | |/commit/ccf1e33a04abd53d58a > | |a3f4d5ea694a4116fab69 > > --- Comment #24 from Nate Graham<nate@kde.org> --- > The dialog was kind of misleading, yeah; "remote control" implies someone > somewhere else trying to take over your computer. What's actually going on is > that the app you clicked on is asking to be able to look at the screen and > control the input devices. > > The dialog was clarified to make this much more obvious recently in > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/ccf1e33a04abd53d58aa3f4d5ea694a4116fab69. > ​
Yes, that's why this bug report is still open. :) The permissions are stored in System Settings > Application Permissions. If you're using Plasma 6.5 and you don't see that page, or it doesn't work, then there's some kind of local misconfiguration on your system or a distro-specific problem.
> 1. Is there the possibility for the xembedsniproxy to do something else > rather than using XTest to propagate events to the applications? From the > comments below, this seems to be the case. For few cases xembedsniproxy was change not to use XTest which cause Bug 498824 :( So this is tricky
(In reply to Nate Graham from comment #26) > Yes, that's why this bug report is still open. :) > > The permissions are stored in System Settings > Application Permissions. > > If you're using Plasma 6.5 and you don't see that page, or it doesn't work, > then there's some kind of local misconfiguration on your system or a > distro-specific problem. I have contacted my distro, that is an arch derivative. The problem might come from arch, then. Let's see. In the meantime, is the corresponding data saved in a location on the filesystem that can be explored with non gui tools too?
Got the solution from my distro. You need a "flatpak-kcm" package. The name seems a bit misleading to me, if this is truly meant to manage *any* application and not just the flatpak ones. I still have a problem, though. I cannot see the permission that I granted to the "sleek" appimage for the remote control. However, I think that the permission should be there, since now sleek starts *without asking for permission*, so evidently it has it already.
(In reply to Sergio from comment #29) > I cannot see the permission that I granted to the "sleek" appimage for the > remote control. However, I think that the permission should be there, since > now sleek starts *without asking for permission*, so evidently it has it > already. AppImage apps don't use any of these permissions. AppImages can do whatever they want.
Apparently they do, when the system tray is involved. Sleek regardless of appimage, directly compiled, etc., asks for it in any case. It is an electron app. You start the application the first time, and it shows a system tray icon. You click on it and it asks the remote control permission. You allow it, and the application window opens. At the same time, another icon is show (so you have two). From that moment on, no more permissions are asked by sleek, since the permission is already granted. I have no clue where this permission might be stored...
As Konrad explained, in that case it's not the app asking for permission; it's actually Plasma asking for permission, due to a technical implementation detail of how certain 3rd-party System Tray icons are supported.
Let me thank you again for your patience in explaining. I am then missing one piece. Let me recap, so possibly you can help me in fixing my understanding: - It is not sleek (or any appimage) using the systray, but is plasma itself. - Does that mean that if I grant the permission for, say, sleek, any other program using the systray in the same way will not trigger a request for permission, since plasma has that already? - If this is a permission for plasma itself and plasma is obviously trusted, cannot this permission be "assigned" by default at some level (plasma packages themselves, the distribution packages for plasma, etc.) - Why cannot I see this permission anymore with `flatpak permissions`? Why cannot I find it in the App permissions page in the settings? - Until a recent past, I was able to see this permission with flatpak permissions (i.e., in the permissions listed by flatpak there was one that, if revoked, caused plasma to ask again, now even resetting all permissions with the dedicated flatpak program, I cannot cause the permission to be re-asked). - I think that there would be a value in documenting where the permissions are stored (in a database? In a file in the filesystem?) I am also trying to better understand what goes on specifically with sleek. This application, in recent versions, not only triggers this request for permission, but after having the permission granted it shows 2 copies of its systray icon. I strongly suspect that one comes from xembedsniproxy, while the other one is produced with a different mechanism, because that two icons "look" differently: one is crisp, the other one seems to be upscaled (furthermore, one of the two is fully functional, while the other has a menu that is not fully functional). The sleek author seem to indicate that this issue appeared after having upgraded the "electron" framework. So is there an electron regression? Or has electron actually fixed some bug that for misterious reasons let it work better with plasma? Can KDE try to coordinate with the developers of electron to ensure that the electron experience on plasma is at the same level as in other DEs?
I'm not 100% sure here, but I believe the permission is indeed being granted to Plasma and not the app. If that's correct, then the reason why it isn't showing up on the App Permissions page is because that page only shows apps, and Plasma isn't an app. So, if all of the above is true, there's definitely a problem of the permission not being accessible later worth addressing.