Looks like it uses some X11 specific KWindowSystem stuff. When I set it on X11, polkit kde authenication dialog uses same taskbar icon as the main application. On Wayland I can see another program in taskbar with a generic Wayland icon.
maybe duplicate of bug 389966
(In reply to Dr. Chapatin from comment #1) > maybe duplicate of bug 389966 I think similar issues (missing desktop file with Icon= attribute) but in different programs.
(In reply to Andrius Štikonas from comment #2) > (In reply to Dr. Chapatin from comment #1) > > maybe duplicate of bug 389966 > > I think similar issues (missing desktop file with Icon= attribute) but in > different programs. Actually only icon->wayland icon is caused by desktop file. But the X11 specific calls that are needed by Action::setParentWidget is not related to kdesu bug.
Thiago informed me that this isn't really portable. Winids shouldn't be sent to other applications on wayland which likely is why this isn't working. With that in mind I doubt this can get fixed. Plus this API isn't actually working with any agent other than the plasma one anyway, we literally feed it the winid over dbus manually and also in a way that is equally !re-entrant as bug #379215 There may be an opportunity to rethink how the auth dialog works in general though, it really shouldn't be a regular dialog window and it even more shouldn't be transient to a random window. Because of how the dialog works currently there's a whole bunch of focus stealing problems and by extension probably some security concerns as well. Other systems (notably windows and gnome come to mind) the auth requests are blocking (covering the entire screen) and always take precedence over anything else going on window-wise. They are much closer in behavior to the lock screen than a random dialog.
(In reply to Harald Sitter from comment #4) > Thiago informed me that this isn't really portable. Winids shouldn't be sent > to other applications on wayland which likely is why this isn't working. > With that in mind I doubt this can get fixed. Plus this API isn't actually > working with any agent other than the plasma one anyway, we literally feed > it the winid over dbus manually and also in a way that is equally > !re-entrant as bug #379215 > > There may be an opportunity to rethink how the auth dialog works in general > though, it really shouldn't be a regular dialog window and it even more > shouldn't be transient to a random window. Because of how the dialog works > currently there's a whole bunch of focus stealing problems and by extension > probably some security concerns as well. Other systems (notably windows and > gnome come to mind) the auth requests are blocking (covering the entire > screen) and always take precedence over anything else going on window-wise. > They are much closer in behavior to the lock screen than a random dialog. Yes, I was also told afterwards that this method is not portable. I do like an idea of full screen authentication dialogs. It does make more sense on Wayland...
Full screen auth dialogs break the use case of copy-pasting your password from a 3rd-party password manager app (or kwallet itself). GNOME does this and there are tons and tons of user complaints about it. So I would be wary of going down that path.
(In reply to Nate Graham from comment #6) > Full screen auth dialogs break the use case of copy-pasting your password > from a 3rd-party password manager app (or kwallet itself). GNOME does this > and there are tons and tons of user complaints about it. So I would be wary > of going down that path. Ok, so what might be other options? This is also why Polkit dialog in KDE Partition Manger is sometimes hidden as you might have seen in that other bug report.
I don't really have one. Is there a way we can make the existing approach work on Wayland?
Well, it works, the window just isn't transient and from what Thiago suggested that can't change. On wayland any app ought to assume that it is the only app with windows and as such winids mean nothing outside the apps context. I have literally no knowledge besides what I'm being told though. And another thing I'm being told is that our current auth dialogs all have an attack vector because they can get focus stolen. Is that still a thing on wayland? I do not know, I'd assume so, probably less though. In any event the current approach is broken because it is a "regular" window it may not be on top, but if it isn't on top users have a hard time noticing what's up. And you can trigger that problem with as little effort as holding alt (giving input to the current window) from what I've seen.
Sorry, I wasn't able to attend Plasma Wayland Bof. Has anybody here attended it? I think focus transfer protocol was discussed there. Would something similar be appropriate to ensure that focus is transferred to authentication dialog?
On Wayland with Plasma, widget windows become normal windows, and cannot be returned to the sidebars of QMapShack: https://github.com/Maproom/qmapshack/issues/691 This is the closest bug report I could find. Should I create a separate report, or is this the same issue? It works fine on GNOME, and on Plasma (Xorg)