search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
20.72k stars 1.43k forks source link

Auto-Type Problems with @ in username #324

Closed rgloor closed 3 years ago

rgloor commented 7 years ago

Expected Behavior

When using Auto-Type, correct USERNAME should be inserted in Form: eg: myname@mydomain.tld

Current Behavior

Auto-Type replaces the @ by a " , so it would enter a wrong USERNAME into the Form: eg: myname"mydomain.tld instead of myname@mydomain.tld

Possible Solution

?

Steps to Reproduce (for bugs)

  1. Go to "site" or app or what-so-ever
  2. Put cursor into the first formfield (eg. for username)
  3. Press Auto-Type Global HotKey
  4. Select the entry

Context

Trying to insert credentials for login into accounts on websites.

Your Environment

Note

It might be not KeePassXC itself, because it could be, that the behavior changed after the last upgrade of KeePassXC. But I am not absolutely sure. However, you might still be able to track down the source of the problem and help fixing it.

rgloor commented 7 years ago

partially "solved" I don't know what happened. All by a sudden, it worked again! In order to test the KeePassXC Auto-Type-Function, I wrote a KeePassXC-DUMMY-entry for KWrite (text editor). And within KWrite, I started Auto-Type and that way could test and see what was handed over from KeePassXC. Now, before shutting down the Notebook, I was closing down all apps and in the end just had the KWrite left. Out of curiosity, I just did another Auto-Type Test, and... ...and surprisingly, it was working again.

So the issue has disappeared for me for now. But I am sure, the source of the problem is not yet solved. Eventually my description can help you tackle down what happened.

I will still keep an eye on it and see, if I can get it to reproduce again.

TheZ3ro commented 7 years ago

From a code point of view, nothing changed in Autotype in the last version. This is the function that replace the {USERNAME} keyword and this loop inject the username's key in the text field.

I can't reproduce this on my PC. I will leave the issue open with a "more info needed" tag, ok?

rockihack commented 7 years ago

This is a keyboard layout issue. Keepassxc and your system use different layouts. Shift + 2 produces a @ character in US layout, but your system uses some other layout where Shift + 2 produces a ".

phoerious commented 7 years ago

Yes, autotype is bound to your keyboard layout. Are you using the app image? We had an issue here where the AppImage always used a US layout on Fedora, although it should have used an AZERTY layout. I was never able to reproduce it.

phoerious commented 7 years ago

Closing since we can't reproduce and it seems to be working for you again. Most likely not a KeePassXC issue anyway.

TheZ3ro commented 7 years ago

I've experienced this the other day when my system layout was IT and Autotype sadly is US-only like @rockihack said. Reopening this.

There is a method to change the autotype layout? If not we can close again

rockihack commented 7 years ago

I never said that autotype is US-only. It seems to be a bug in xcb autotype or your display server.

https://github.com/keepassxreboot/keepassxc/blob/1f6f7b614ce3528f24958d2025289b96665119fe/src/autotype/xcb/AutoTypeXCB.cpp#L223

phoerious commented 7 years ago

Problem seems to be that autotype sometimes doesn't respect the user's keyboard layout and then falls back to a US layout. But I have no idea why. Maybe it has something to do with: https://bugreports.qt.io/browse/QTBUG-30911

rgloor commented 7 years ago

Still not fixed. Had problem again. Yesterday, just installed KeePassXC v2.1.3. and it worked again. After restarting the system this morning. Problem is here again. Closed KeePassXC, restarted it again. Now working again..... but not having any clue, what will trigger the misbehavior again. So issue is still open.

rgloor commented 7 years ago

Tracked it down a bit: When I shut down my system (openSUSE LEAP 42.2), I usually leave KeePassXC running. So when I start it up again, KeePassXC comes up as well after login. What I found:

So when KeePassXC is starting within the start up process / login process of the system, it might initiate before the correct keyboard layout is defined.

Is there a startup / login sequence where KeePassXC might wait for a certain event to be passed before it starts up or defines the keyboard? Just a thought.

droidmonkey commented 7 years ago

If you want to wait for events, use udev or similar. I would just add it to the end of your .bash_profile or equiv file.

phoerious commented 7 years ago

I really think this is tied to the Qt bug I linked above. KeePassXC gets the correct layout when it is already set, but when it changes during runtime, KeePassXC doesn't notice.

frostasm commented 6 years ago

I have similar problem with "Ukrainian" keyboard layout and I wrote a small fix. Before "auto-typing" procedure keepassxc change the system layout to "English" and after "auto-typing" return back the original layout.

image

droidmonkey commented 6 years ago

That's great! It would be even better if the user could set a desired keyboard layout in settings. Default being "us".

frostasm commented 6 years ago

@droidmonkey I can prepare PR with related changes. But at the moment my fix is relevant only for Linux, what about the others operation systems?

frostasm commented 6 years ago

And one more note, method with changing system keyboard layout only works assuming that the "us" layout will be the first in the list of layouts, otherwise, changing the layout does not help :(

image

droidmonkey commented 6 years ago

This definitely requires more discussion and investigation, but i think we are on the right track. I have not heard any complaints about autotype on windows or mac with alternate keyboards. This might be a linux only change and can be ifdef'd as such.

stratacast commented 6 years ago

I can confirm this is not an issue on Windows 10, but is an issue with all my Linux boxes

frostasm commented 6 years ago

@droidmonkey @TheZ3ro @phoerious @weslly can we use GPL code from other projects in KeePassXC project?

I use XKeyboard class from nonpop/xkblayout-state project. I used that class for changing system keyboard layout.

droidmonkey commented 6 years ago

As long as you keep the license header and add the origination information to the COPYING file.

skontar commented 6 years ago

As far as I can tell, the Autotype feature just types as if the active layout would be US. So if my password contains numbers like "234" it is going to type "ěšč" on CZ layout. One workaround I have is a script, which changes the layout before it sends the autotype key combination (however it does not change back).

    setxkbmap -model pc104 -layout us -option grp:caps_toggle
    xdotool keyup super
    xdotool key alt+ctrl+a

In the application you can probably store the current layout, switch to US, type, switch back.

rgloor commented 6 years ago

Just an Idea: Very rarely, people change keyboards during the day. So,

Alternatively, if it is not slowing the app down too much,

Just my 2 cents.

TheZ3ro commented 6 years ago

@frostasm any news?

frostasm commented 6 years ago

I made a temporary solution (change system layout at every auto-type action), but in my opinion it is a ugly hack. It is probably better to find another solution to the problem or use xdotool library.

@TheZ3ro you can see my changes in this commit

rawbone7 commented 6 years ago

Came across this issue just recently when I got a Dell XPS 15 with the UK keyboard layout. It's possibly a very rare edge case but my set up is as follows:

I get the behaviour described above where the @ sign in an email address is typed as a " but only when autotyped in a VM running in VirtualBox. Both the host (solus) and the guest (ubuntu) are set to UK keyboard layout, but when you autotype from KeePassXC into the VM it goes wrong.

Not a major issue in the end - copy and paste via clipboard works without problems just though it was an interesting quirk.

rgloor commented 6 years ago

@robinedser Did you have KeePassXC on "autostart"? Or did it happen when you manually started KeePassXC after the OS was up?

rawbone7 commented 6 years ago

It's not on autostart, I open it manually after the OS is up. Then there are no issues autotyping into a terminal or browser on the host - just autotyping into a Virtualbox Guest window. Could even be a Virtualbox issue I guess.

ghost commented 6 years ago

I can reproduce this problem with the AppImage on QubesOS, which is inside a VM because of how QubesOS works.

mwip commented 5 years ago

Still have the same problem. Working on a

As @rgloor guessed, I switch between two layouts throughout the day (EN_US and DE). Whenever I am working on the DE layout, the auto-type will insert " instead of @. This occurs for both autostarted as well as manually started keepassxc instances. On my private machine (Arch linux, KDE Plasma, keepassxc 2.3.4, two layouts [EN_US / DE]) I never stumbled over this behaviour.

jtrh commented 5 years ago

I experienced this problem today.

My system's characteristics are:

I have multiple keyboard layouts configured in Xfce: English (US) (set as default), and Spanish. When I change the current keyboard layout to Spanish, every application respects it, except KeePassXC's auto-type, which insists on using English (US).

The issue seems to be that KeePassXC always uses the default keyboard layout, instead of the current layout. If you have multiple layouts configured in Xfce, you can change the current layout by using a tool such as the Keyboard Layouts panel plugin.

I "fixed" the issue by changing the default keyboard layout to Spanish. However, if I try to change the current layout to English (US), the problem returns, but with the languages reversed.

achilleas-k commented 5 years ago

I had this same issue on one machine and not another (with nearly identical software setups) and I found the setting which, in my case, solved the issue. Not sure if this information will help or make things more confusing.

I have two layouts: UK and Greek.

OS: ArchLinux KeePassXC version: 2.3.4 Locale: en_GB.UTF-8 Desktop environment: KDE Plasma

In Plasma, the keyboard layout options have an option for policies: Global, Desktop, Application, Window. It was set to Window, meaning the layout is allowed to be different for different windows of the same application. Switching it to Application (which means the layout stays the same within windows of the same application) instead solved the issue for me. Even more interestingly, switching it back to Window doesn't recreate the issue.

I don't know what this means. It's possible whatever window context auto-type was working in was "stuck" (possibly from when I first set up the system or some time before setting up layouts) in a US layout and changing the policy made it inherit the application's layout (which is now UK).

Like I said, not sure if my experience helps, makes things more confusing, or if I'm just adding noise, but I thought it might be interesting.

sxe commented 5 years ago

At this point I am pretty convinced this is a problem related to the systems keyboard layout on Linux. It's not just that @ is printed as ". Today I noticed that also y is printed as z. I have a "German keyboard" and exactly this happens when you use an English keyboard layout cause y and z are switched. German has qwertz not qwerty. It looks like KPXC is not using the correct layout.

Her is my layout after fully booted:

$ setxkbmap -query | grep layout layout: de

My system is set to this after fully booted and KPXC is running:

LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

These two are en_US.UTF-8 at boot time as well but get changed to de_DE.UTF-8 from KDE after boot.

LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8

Not sure how relevant the locale is, I just wanted to add it.

Hope this helps.

Debug Info

KeePassXC - Version 2.4.0 Revision: c51752d

Libraries:

Operating system: Arch Linux CPU architecture: x86_64 Kernel: linux 5.0.4-arch1-1-ARCH Desktop environment: KDE Plasma

Cheers

LaugeGregers commented 5 years ago

I too am experiencing this problem. I usually use three different keyboard layouts, swedish sv, danish da and US english en. Swedish is the primary one. In Swedish and Danish layouts, @ is typed as {ALT GR}+{2}. When the keyboard layout is sv or da, auto-typing @ works, but when the keyboard layout is en auto-typing @ becomes 2. I start KPXC manually after logging in. I tried allowing for different windows to have different keyboard layouts. It is the keyboard layout in the window being typed to that needs to be sv or da for the auto-typing to be correct, not the KPXC window.

Debug info

KeePassXC - Version 2.4.3 Revision: 5d6ef0c

Qt 5.12.1 Debugging mode is disabled.

Operating system: Fedora 30 (Workstation Edition) CPU architecture: x86_64 Kernel: linux 5.1.12-300.fc30.x86_64

Enabled extensions:

Cryptographic libraries: libgcrypt 1.8.4

anonymous133 commented 5 years ago

I have the same experience.

As soon as I call "setxkbmap us -variant colemak" to switch keyboard layout to colemak, autotype does not work correctly anymore.

Switching manually to "setxkbmap us" before autotyping does fix the problem. So it would be great to have keepassxc check which keyboard layout is active before autotyping.

I'm using i3 and have different keyboard layouts on different workspaces to which I switch dynamically.

I'm on arch.

Initially colemak is my selected keyboard on boot which does work with autotype. But regardless if it is the active layout calling "setxkbmap us -variant colemak" again (even if it is already the active layout) breaks the autotype function in that it defaults to US layout.

mwip commented 5 years ago

So, I ran into this problem again. However, now it is not with multiple but only one keyboard loaded. It is the standard German keyboard. Sys. specs: Arch Linux (Kernel 5.2.5) WM/DE: KDE Plasma KeePassXC 2.4.3

As with mutliple keyboards, the loading EN_US keys solves the problem.

stefan123t commented 4 years ago

I just want to add to the cause that it has something to do with the primary layout of your Desktop too. In the past my primary layout used to be us and secondary layout de.

I have been used to run KeePassX with this bug for years, i.e. I usually avoid z and y in newer passwords. Though when typing a password I am still used to switch to us layout first and then hitting autotype.

Now with a new system I installed (linux mint 19) I have opted for primary layout de and secondary layout us. This is when the problem with the @ in the username started to occur to me too, i.e. I get a q character instead.

After switching to KeePassXC 2.3.1 I have been digging your issues and reading up on the Qt Bug mentioned above. I guess this could be related, as apparently the primary layout chosen is somewhat changing the behaviour of the problem described.

It seems that KeePassXC 2.3.1 utilizes the primary keyboard for typing correctly, though any secondary active layout will experience the issue.

using de as primary layout:

$ setxkbmap -query | grep layout
layout:     de,us

de user.name@email.com  ist&bleibtg3h31m
de          ^ alt-gr+q     ^ shift+6
us user.nameqemail.com  ist^bleibtg3h31m
us          ^ (alt-gr)+q   ^ shift+6

using us as primary layout:

$ setxkbmap -query | grep layout
layout:     us,de

us user.name@email.com  ist&bleibtg3h31m
us          ^ shift+2      ^ shift+7

de user.name"email.com  ist/bleibtg3h31m
de          ^ shift+2      ^ shift+7
phoerious commented 4 years ago

Perhaps it's also possible that your display manager's layout leaks into your session, which can be particularly problematic if KeePassXC starts early. This is one of the downsides of this whole legacy X11 stack that your display manager and your session are two totally different things and don't know a thing about each other. To this day I find it very difficult to make my login screen somewhat consistent with my session or my lock screen.

Furthermore, Qt appears to be unable to pick up in-between layout changes, at least if started in the form of an AppImage. This is less problematic on wholly Qt-based desktops like KDE, where it seems to be working just fine.

stefan123t commented 4 years ago

Regarding the layout switches I have made the above changes without quitting KeePassXC 2.3.1, hence the session information should remain. Though a shell expectedly returned different setxkbmap -query results after switching layout order in cinnamon-settings keyboard.

@phoerious I am running Cinnamon under Mint 19, hence I should only have libqt and KeePassXC in the play, though I do not know if that makes any difference.

Having said that, switching the two layouts back to the old "us, de" order, I am used to the behaviour. Just wanted to note that the primary keyboard layout seems to play a significant and reproducible role in the way KeePassXC behaves on my system with multiple keyboard layouts.

technodrome commented 4 years ago

Also keep encountering this issue with customized layout. KXR does not respect at all what is entered in the password field. For example, if you swap y and z on your keyboard, it will type what it expects on the English keyboard which makes auto-typed passwords invalid.

I had to add dedicated EN keyboard to which I have to manually switch each time I want to use KXR's auto-type! Great usability "feature", by the way.

Would make total sense to actually internally switch to en-us keyboard while typing the password if KXR actually has such implicit requirement. This would be at least way better than ignoring this issue for non-English users for three years.

phoerious commented 4 years ago

We are not ignoring the issue. We are simply unable to reproduce it and therefore don't know how to fix it.

stefan123t commented 4 years ago

Dear @phoerius it should be sufficient to install two keyboard layouts in your desktop environment. I have given en and de as examples. You can use a custom dummy auto-type entry with a couple off passwords using special character that are located on different key locations on these two layouts, eg. „ and @ or q depending on your primary layout and use auto-type in a Texteditor for reproducing. Hence there is not much involved except KeepassXC, XKB and a huge pile of libraries. Could it be the case that Keepass, KeepassX and KeepassXC use keycodes for Autotype and obfuscation instead of plain text letters ? Kind regards, Stefan PS: I do not think you are ignoring this issue, just let us know if you still have problems reproducing. Maybe I need to detail the steps for reproduction?

phoerious commented 4 years ago

Thank. I was able to reproduce the issue with multiple layouts if the currently active layout is not the default layout. As soon as I move the non-English layout to the top of the list, KeePassXC picks it up and types the correct letters. This is pretty much what I noted before about layout switches. I'll see if I can find a fix for that.

stefan123t commented 4 years ago

Dear Janek, I think you are right regarding the distinction between current active layout and default layout. I keep my fingers crossed so you can somehow query the current active layout from the OS / desktop env in order to use the right keycodes in auto-type obfuscation. Kind regards, Stefan

ohnonot commented 4 years ago

As soon as I move the non-English layout to the top of the list, KeePassXC picks it up and types the correct letters.

Interesting. I wonder what that list is - something provided by the desktop environment you use? I wonder if keepassxc expects a DE to be present and draw keyboard related info from that, and defaults to US if it can't find it?

I use no DE on Linux, English as UI language and a non-US keyboard layout. I don't think I have a "list" of keyboard layouts:

$> setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105
layout:     fi
options:    grab:break_actions
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete+xfree86(grab_break)
symbols:    pc+fi+inet(evdev)
geometry:   pc(pc105)
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)" };
    xkb_types     { include "complete"  };
    xkb_compat    { include "complete+xfree86(grab_break)"  };
    xkb_symbols   { include "pc+fi+inet(evdev)" };
    xkb_geometry  { include "pc(pc105)" };
};
$> localectl
   System Locale: LANG=en_IE.UTF-8
       VC Keymap: fi
      X11 Layout: n/a
phoerious commented 4 years ago

KeePassXC uses your X keyboard map. If you have multiple layouts configured, of which one is selected dynamically via xkb extensions, it won't see it, since the order doesn't change. Your active layout has to be the first layout in the list.

stefan123t commented 4 years ago

Dear @ohnonot, thanks for your reminder, as you are not using a DE to configure a list of keyboard layouts you are only having one layout, probably always the default, ie. in your case fi.

I just verified your queries on my system and I do have the list of layouts specified in both layout: us, de and xkb_keymap { xkb_symbols { include "pc+us+de:2+inet(evdev)+group(alt_shift_toggle)" }; specified.

$ setxkbmap -print -verbose 10 Setting verbose level to 10 locale is C Trying to load rules file ./rules/evdev... Trying to load rules file /usr/share/X11/xkb/rules/evdev... Success. Applied rules from evdev: rules: evdev model: pc105 layout: us,de variant: , options: grp:alt_shift_toggle Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols: pc+us+de:2+inet(evdev)+group(alt_shift_toggle) geometry: pc(pc105) xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+de:2+inet(evdev)+group(alt_shift_toggle)" }; xkb_geometry { include "pc(pc105)" }; }; $ localectl System Locale: LANG=en_US.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 VC Keymap: n/a X11 Layout: us X11 Model: pc105

As you can see my primary layout of xkb_symbols is us and the secondary layout is de.

I have learned from the following Unix/Linux Stackexchange question that there are probably two ways to determine the current active xkb_symbol layout.

How do I get current keyboard layout? https://unix.stackexchange.com/questions/12072/how-do-i-get-current-keyboard-layout

1) a small tool called xkblayout-state https://github.com/nonpop/xkblayout-state

2) the LED status byte visible in set -q This does work only for up to two layouts, though

I have double checked whether both would work by using a third layout (us,de,fi) as a tribute to your comment. While the former works the latter does only tell us whether we are on the primary layout or any secondary/third/... layout whatsoever.

$ setxkbmap -print -verbose 10 Setting verbose level to 10 locale is C Trying to load rules file ./rules/evdev... Trying to load rules file /usr/share/X11/xkb/rules/evdev... Success. Applied rules from evdev: rules: evdev model: pc105 layout: us,de,fi variant: ,, options: grp:alt_shift_toggle Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols: pc+us+de:2+fi:3+inet(evdev)+group(alt_shift_toggle) geometry: pc(pc105) xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+de:2+fi:3+inet(evdev)+group(alt_shift_toggle)" }; xkb_geometry { include "pc(pc105)" }; };

$ localectl System Locale: LANG=en_US.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 VC Keymap: n/a X11 Layout: us X11 Model: pc105

us: $ ./xkblayout-state print "%s" us $ xset -q | grep LED auto repeat: on key click percent: 0 LED mask: 00000002

de: $ ./xkblayout-state print "%s" de $ xset -q | grep LED auto repeat: on key click percent: 0 LED mask: 00001002

fi: $ ./xkblayout-state print "%s" fi $ xset -q | grep LED auto repeat: on key click percent: 0 LED mask: 00001002

@phoerious: Janek, would you be able and willing to compile a fix from the XKeyboard.cpp class given in the github ?

Kind regards, Stefan

stefan123t commented 4 years ago

Dear all,

@droidmonkey so from the current analysis (multiple keyboard layouts/symbol xkb maps) I would say this is definetly a Linux only issue and can be ifdef'ed out for Win and probably also for Mac.

I do not know if the proposed symbol parser in the xkblayout-state tool would be also targeting users having reported this problem for manual changes using setxkbmap reported by @anonymous133.

But I assume that automatic layout changes depending on window focus as reported by @achilleas-k and @LaugeGregers are probably even out of scope for this fix, as KeepassXC would somehow need to get the target window's dynamic keyboard layout setting. But you are free to test the xkblayout-state wrapper from github to verify their use-case.

Kind regards, Stefan

ohnonot commented 4 years ago

I must admit that the issue has not bothered me for a while, and I blurted out my previous comment without re-checking the facts. It's (almost) always an interaction between kepassxc's autotype and mybrowser (Firefox), and I suspect that something has recently changed on both sides. I have only one username that has an "@" in it, and that has worked as expected yesterday. But my experience over time has been that this issue comes and goes...

And yes, I clearly have only one layout in "the list": xkblayout-state print "%S" fi Note the capital 'S', it should list all layouts.

stefan123t commented 4 years ago

@ohnonot and @achilleas-k , thanks for feedback and double-checking on your side and the pointer to "the list" of layout symbols. I have added another layout variant to my mix of layout symbols, ie. german with nodeadkeys.

$ ./xkblayout-state print "%s_%v" de_nodeadkeys

xkblayout seems not fancy enough to print both layout symbols and layout variants in one line, but I guess we get the picture.

$ ./xkblayout-state print "%S %V" us de de fi

nodeadkeys

$ _

ohnonot commented 4 years ago

I must admit that the issue has not bothered me for a while, and I blurted out my previous comment without re-checking the facts. It's (almost) always an interaction between kepassxc's autotype and mybrowser (Firefox), and I suspect that something has recently changed on both sides. I have only one username that has an "@" in it, and that has worked as expected yesterday.

And at least one more login that I know to have been problematic in the past. Neither has bothered me for a long time; I have no idea whether keepassxc changed or firefox or both. I consider the issue resolved.