AutoType not available when using Wayland

[ganomi46]

Expected Behavior

AutoType should be available as under X.

Current Behavior

AutoType not available in Wayland

Steps to Reproduce (for bugs)

Login to Plasma Wayland Open KeePassXC You will there are no auto login options

Operating system: OS Debian SID amd64

[droidmonkey]

Are you referring to AutoType??

[ganomi46]

Hi.Yes, thatbis whatnI meant.-JiriOn 12 Sep. 2018 2:14 am, Jonathan White notifications@github.com wrote:Are you referring to AutoType??

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

[Whompithian]

I can confirm lack of Auto-Type options using Plasma Wayland.

OS: 4.14.65-gentoo x86_64 plasma-5.46.0 wayland-1.15.0

[phoerious]

Auto-Type cannot work on Wayland due to security restrictions for which we haven't found a solution yet.

[rockihack]

I implemented autotype for wayland, still needs some work though.

https://github.com/rockihack/keepassx/blob/wayland-autotype/wayland.txt https://github.com/rockihack/keepassx/tree/wayland-autotype/src/autotype/wayland

[apollo13]

It might be worth to look what https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon does. I seems to allow writing arbritrary key sequences to windows.

[tmccombs]

fwiw, there is a keepass plugin that supports this (https://keepass.info/help/kb/autotype_wayland.html), it does require access to /dev/uinput though.

For wlroots based compositors (such as sway) the input-method protocol (https://github.com/swaywm/wlroots/blob/master/protocol/input-method-unstable-v2.xml) or possibly the virtual-keyboard protocol (https://github.com/swaywm/wlroots/blob/master/protocol/virtual-keyboard-unstable-v1.xml) may allow implementing AutoType

[curiosityseeker]

I'm using KeePassXC on Arch Linux with Wayland (on KDE) in combination with ydotool, specifically ydotool-git in the AUR. And voilà - Autotype works flawlessly!

So perhaps it's possible to integrate ydotool's approach in KeePassXC directly?

[droidmonkey]

Oh nice!!

[apollo13]

Mhm, seems like it has a client/server structure because it uses /dev/uinput which requires (usually) root permission. Still better than no autotype I guess :D

[curiosityseeker]

Yes, it seems to be similar to how KeePass does it with KPUInput.

[apollo13]

https://gitlab.com/dogtail/dogtail/ seems to use the accessibility features in gnome and kde to send text to applications without the need of uinput and as such without any extra daemon.

[apollo13]

Ok, dogtail uses ponytail on wayland which I linked above already. Seems to be a rather heavy solution :/

[droidmonkey]

I think I'll opt for https://github.com/keepassxreboot/keepassxc/issues/2281#issuecomment-425932745 solution

[phoerious]

Using the DE's accessibility features is the only correct way to implement it. I only wish there were some kind of standard interface and not several largely incompatible ones, like there always is on Linux.

[MAFLO321]

I'm not very familiar with Wayland in deep, but can text-input-v3 protocol be used to solve the virtual-input problem? KDE Plasma's and Gnome's Compositors both support it.

already mentioned by https://github.com/keepassxreboot/keepassxc/issues/2281#issuecomment-657179359

[phoerious]

Perhaps, need to check. Thanks for the pointer.

[ztNFny]

I'm using KeePassXC on Arch Linux with Wayland (on KDE) in combination with ydotool, specifically ydotool-git in the AUR. And voilà - Autotype works flawlessly!

So perhaps it's possible to integrate ydotool's approach in KeePassXC directly?

Could you elaborate on that? How can KeePassXC be configured to use ydotool? I thought to just use it with cmd://, but then the input just goes .. no idea where.

[sam9032]

I don't have KDE Plasma to test right now, but under Gnome 40 with wayland it works ootb. Is this issue still present in plasma?

[vimpostor]

I don't have KDE Plasma to test right now, but under Gnome 40 with wayland it works ootb. Is this issue still present in plasma?

I just tested in Plasma and it doesn't work there. Neither global autotype nor manually choosing autotype from Keepass itself are working. I am curious, does anyone know how this is working in Gnome? As far as I can see in the codebase, there is no implementation merged for Wayland yet, so I don't get why this is working in Gnome ootb for you.

Tested on Plasma 5.21.4 on Arch btw.

[curiosityseeker]

I just tested in Plasma and it doesn't work there. Neither global autotype nor manually choosing autotype from Keepass itself are working.

Tested on Plasma 5.21.4 on Arch btw.

I'm also using Plasma with Wayland on Arch, and KeepassXC works flawlessly in combination with the KeePassXC-Browser add-on both in Firefox and Brave. If it doesn't for you: are you using Firejail?

@ztNFny : I removed ydotool - it seems it's not (no longer?) necessary.

[ztNFny]

I'm also using Plasma with Wayland on Arch, and KeepassXC works flawlessly in combination with the KeePassXC-Browser add-on both in Firefox and Brave.

This issue is about AutoType, not browser extensions. That's a separate mechanism using native msgs.

[sam9032]

I have now tested the whole thing with Gnome 40 again in more detail. So under X-org as well as under Wayland.

I tested the global autotype function under the "General" tab and the entry based autotype function both with different websites and the Spotify client. I leave out the browser addon, as it is not part of this issue.

As far as I can tell for my test, both (x-org and wayland) work almost the same. No matter how I have my login field filled in (global or entry), both manage to type in the selected entry. Under Wayland, both have a problem with the "@" symbol in the username/password for certain applications (ex: Spotify) and just don't type that. In Firefox, having web pages type something in is not a problem.

Under both Wayland and X-Org the global function only shows entries with matching title, links do not work. Typing the selected ones then works again without problems as long as the fokus is on the first input field (username).

[droidmonkey]

Thank you for all the input but we don't need any further discussion on this. What you are seeing is Auto-Type happening between applications running on xwayland backend. You are still communicating through an X11 server between keepassxc and the other application. Wayland is just receiving the output and passing it to the compositor.

There is no support, currently, for Auto-Type in a purely Wayland mode of operation.

[CIAvash]

I know it's been said that there is no need for further discussion, but if keepassxc knows the window is running on wayland or xwayland or X11, then it can do something like using wtype for wayland windows and xdotool type for X11.

I tried and it works, you just have to know the type of window.

[zsolt-donca]

... if keepassxc knows the window is running on wayland or xwayland or X11, then it can do something like using wtype for wayland windows and xdotool type for X11.

The ydotool also works in a display server-agnostic way, working both on Xorg and on Wayland.

I haven't tried this personally, though.

[droidmonkey]

This program requires access to /dev/uinput. This usually requires root permissions.

[Aetf]

Maybe it's possible to implement the input method protocol under Wayland as a way to perform autotype?

https://dcz_self.gitlab.io/posts/input_method/#:~:text=The%20purpose%20of%20an%20input,and%20gives%20it%20to%20applications

[Zocker1999NET]

I use sway and use https://github.com/atx/wtype (uses input method protocol of Wayland, as I know) to insert keys, works without root and really easy. Maybe this could be used to implement it here?

[MarkJaroski]

I understand from droidmonkey's post that additional commentary isn't necessarily welcome on this issue, however this is the only thing right now preventing me from moving to Wayland, so I'd like to at least have some understanding of what the blockers are, and whether they're more of a global problem with Wayland, or if they're just a KeepassXC problem. Again, I apologise in advance if I'm creating noise, but it would be good to have a little bit of information about what if anything could move this forward.

[droidmonkey]

What can move this forward?

A wayland expert that programs a virtual keyboard interface for keepassxc and some way to pull window titles from the desktop environment that works across all variations of Linux desktop envs (gnome mutter, kde kwin, Sway, etc etc).

Wayland has taken the stance of "Wayland is not a compositor" and has ceded that responsibility to the various desktop environments. This creates the situation where each desktop env has its own set of extended protocols and internal interface api (and maybe even permissions) to poll for information that was openly available via X11 server in the past. This includes window titles and switching between windows. Wayland has taken the stance that every client is isolated and should have no knowledge of any other client. This means keepassxc cannot "find out" about other windows unless the compositor exposes that information in some other fashion.

So this isn't really a "why can't you do this in wayland" discussion because that is not where you do this anyway. Wayland is just a protocol for drawing windows and sending/receiving inputs to the compositor.

https://way-cooler.org/book/wayland_introduction.html

https://stackoverflow.com/a/64030239

[MarkJaroski]

Would it help, maybe, to get freedesktop.org's attention?

[droidmonkey]

No it wouldn't help in any way, they are not going to change the protocol to violate its core tenants. Further, each compositor can choose not to implement portions of the protocol that may expose client to client information. GNOME has already taken this stance.

[MarkJaroski]

So, I guess there is no generic way forward?

What about doing something completely different, something like a browser plugin, but at the desktop level?

I realize that I'm getting off-topic now, but if you have any ideas I might be able to help hack some kind of POC together.

[MarkJaroski]

Here's what might be a dumb idea: what about using the virtual keyboard interface? Keepass2Android does this, and while it's a bit of a pain in the neck to switch between keyboards every time you want to type a secret it works.

[ccoenen]

Barrier and Synergy have the same problem and it seems they also don't have a clear way forward right now.

[tmccombs]

I think there is a path forward for wlroots-based DEs and possibly KDE. But it seems unlikely GNOME will let non-GNOME apps do this sort of thing anytime soon.

[MarkJaroski]

Here's a left field idea: what about virtual USB?

[foobar13372]

Are there any news here? Working approaches/workarounds?

[slagiewka]

Has anyone considered libei?

[droidmonkey]

Keyboard input is actually not the challenge here. The issue is window title harvesting and ability to read the window title to use global auto type capability. That is currently impossible through the Wayland protocol and no Wayland based compositors have exposed this as a standard or defined interface.

[lennartfricke]

But wouldn't it be ok, if the auto-type feature is limited to typing into the last focused text-field/-area. It would mean one has to select the correct entry beforehand or in a selection frame displayed on global auto-type. But at least some kind of auto-type would work. Or am I missing something here?

[apollo13]

I think that would at least be a middleground till the rest of the missing autotype functionality is possible (ie querying the window list and active windows)

[Ferk]

An alternative would be to add an option to keepassxc commandline (or keepassxc-cli) in which you can pass the title of the window as parameter and have it open the autotype dialog.

Then rely on the compositor/user to configure a shortcut to call the command appropriatelly with the required info.

At least in Sway it would be viable to configure it that way (and in fact, this might be the only way to set a "global shortcut" since I'm not sure KeepassXC is able to configure such shortcut from its settings, it's not working right now in Sway). And I expect the same from any compositor that allows any sort of flexibility / scripting for its shortcuts. If they don't offer it then it'd be their fault, imho.

Maybe for Gnome a Gnome Shell extension could be written that calls the same autotype command (I expect Gnome Shell should be able to support that at least).

[Aetf]

An alternative would be to add an option to keepassxc commandline (or keepassxc-cli) in which you can pass the title of the window as parameter and have it open the autotype dialog.

Or as a dbus api. It will be usable in kde via kwin script, then. And you can still call it on command line using dbus-send or busctl

[MarkJaroski]

I've bitten the bullet to speak, and have started developing integrations everywhere using this, with the goal of making autotype unnecessary:

https://github.com/hargoniX/keepassxc-proxy-client

[droidmonkey]

Sweet! Good solution

[Ferk]

https://github.com/hargoniX/keepassxc-proxy-client

As far as I understand, it only supports looking up entries based on their URLs, not the Window Titles configured in the auto-type associations, which might also have different key sequences for different Windows (or more than one key sequence, like for windows requesting the TOTP).

Is it possible to query entries based on the Window Titles via keepassxc-proxy? what about obtaining the configured key sequences?

[MarkJaroski]

Well, it's not autotype, so it really isn't about the window, rather the idea is to find a hook in the application itself, or in the worst case to set up a global key binding.

[rldleblanc]

As a work around for KDE on Wayland (Debian Bookworm) is to run KeepassXC through Xwayland. I was able to do this with WAYLAND_DISPLAY=no keepassxc and it seems to have restored global AutoType shortcuts. I've only tried it on a couple of windows though. Thought I'd share.