EDIT: Lol, it doesn’t actually work +___+ It is enabled in KeepassXC but it just doesn’t do anything. Welp.
Here’s a neat trick I just found out (with a hint from here):
In Wayland you can’t use KeepassXC’s very cool Auto-Type feature (it’s somehow Qt’s fault?) but if you installed it as a Flatpak you can go into KDE Settings, search for “Flatpak Permission Settings” and in the settings for KeepassXC under “Advanced” you can disable “Wayland Windowing System” to make it work. Nice!
This is because Wayland doesn’t allow it to read window titles. Keepass and KeepassXC uses the window title to identify which entry to use. If you have no title, you can’t find the entry. That’s why it will not work with Wayland and never will work, until Wayland allows it to read window titles.
XWayland, which is forced with your workaround, is not Wayland.
That’s at least for me, the main reason not to switch to Wayland. I have no idea why Wayland doesn’t allow reading window titles. There is absolutely no security or performance benefit of this behavior. For me it’s either a bug or a design failure. Or simply bad behavior.
With how easy it is to change window titles, I’m surprised this feature ever made it into Keepass in the first place. Surely it also tries to do some kind of executable matching, right?
With the lack of proper window security and the ability for applications to snoop on each other’s messages, I have strong doubts about the security of such a mechanism.
As for why Wayland disallows reading other windows’ anything: Wayland was designed so that the window manager manages the windows, and to no longer provide one big common pool of windows and controls that can all muck about with each other. Other operating systems have used variants of this mechanism for years for security reasons (for example, Windows keyloggers can’t capture the password you type into the UAC prompt like the more naive X prompts will let you, and low integrity processes like the stuff launched from an exploited browser don’t get access to high integrity processes like control panel).
I understand why you may disagree with this design, and I’m sure X11 will stick around for the coming few years despite most X developers now working on Wayland and X being put in maintenance mode.
Perhaps it’s interesting to note that there is a relatively easy way to query open windows in Gnome through the DBUS API, by running a piece of extension script. I suppose someone could write a KDE plugin that exposes an API for applications as well. Don’t count on any of this making it into a stable API, though.
That window titles can be easily changed is quite true, so all applications I know monitor such changes and abort the autotype on request when a change is made. But as already said, this is not a security feature, at least not a useful one.
Monitoring the application itself makes no sense for a password manager. As you write yourself, it’s easy to customize the title. All applications make use of this. It is already changed when the tab in the browser changes, a new page is loaded or similar. The same is true for non-browser applications. Windows also allows read access to window titles.
What the Wayland developers do is, in my opinion, gross mischief or ignorance regarding window titles. The password manager needs a simple way to assign a window to an entry, which should be the same for all applications. This should be the same for all DE’s, window managers and OS. The simplest is the window title. The status bar makes no sense and an API would have to be the same or at least similar across all DE’s, window managers and OS. Such a thing does not exist. To implement something like that only for KDE is too niche. This would have to be implemented and established, if already for the broad mass. So also for Gnome, Mate, Cinnamon and all the others. Not to forget, this must also work for Windows and MacOS in a similar way.
I disagree, I have full trust in the intentions and design capabilities of the Wayland developers. The core of them also developed X.org, after all.
I do agree that there should be some standard way applications should be able to provide accelerators to specific application, but copying things like window titles and X specific APIs is the wrong approach.
Wayland has the Foreign toplevel list protocol to get application IDs for every top level window. I think that API should provide ample capabilities to a password autofill service. It even provides window titles (not useful for matching applications, but very useful for picking default names for newly created entries and audit logs). It doesn’t provide access to windows in the background, but that sounds like a good design decision to me; I can’t think of a reason to password fill a background window.
I absolutely never trust blindly in such things. I have never seen a plausible explanation why this is a security feature.
When there are dev’s from X11 involved, this is fine and it seems that this leads to decisions which prevent from current X11 issues. But it absolutely is no guarantee that everything is trustable. I’m not that expert, but your mentioned link points in the right direction. But as long this isn’t supported in the wide mass, it’s only a wish…