Keepassxc: Autotype doesn't support some KeePass codes

[TheCycoONE]

Symbols supported in KeePass 2 autotype, e.g. + for shift, are not supported in KeePassXC resulting in bad autotype behaviour for imported or shared databases.

Expected Behavior

The autotype sequence I use in KeePass is: +{END}{UserName}{TAB}+{END}{Password}{ENTER} which ensures that the username and password replace whatever is already entered in the field. (shift + end)(tab)(shift + end)(enter).

Expected behaviour would be to match the list from http://keepass.info/help/base/autotype.html

Current Behavior

In KeePassXC I'm instead seeing the + prepended on my username and password.

Context

I share the same database (through frequency syncing) across a number of devices, and operating systems. On Windows I'm running KeePass 2, and on Linux and OSX I'm using KeePassXC. Some of the sites I log in to automatically populate the username and password fields, so I added the +{END} sequence to my autotype default to address those pages.

Debug Info

KeePassXC - Version 2.2.0
Revision: caa49a8ef3ee28ed478192389b21d61107b3b8e0

Libraries:

• Qt 5.9.0
• libgcrypt 1.7.7

Operating system: macOS Sierra (10.12)
CPU architecture: x86_64
Kernel: darwin 16.7.0

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey

[TheCycoONE]

It seems for my use case, the solution would be to use {CLEARFIELD} which is supported by both.

[TheZ3ro]

Yes, you should use {CLEARFIELD} when possible. We don't have implemented the + special character right now.

[droidmonkey]

The plus special character seems like a mistake to me. Why have it different then the given standard of wrapping commands with { }

[TheZ3ro]

@droidmonkey I don't know but plain plus + is equal to the SHIFT button, if you want to print the plus symbol you should use {+} according to KeePass reference.

I will implement such symbols for 2.3.0 version to keep our autotype compliant to those ref.

[droidmonkey]

That is so backwards it makes my head hurt. {+} should be {SHIFT} to match the rest of the convention! I understand its that way in KeePass but OMG.

[TheCycoONE]

@droidmonkey If it helps your conceptual model, the three replacements without {..} are modifiers not substitutions: + for shift, ^ for control and % for alt.

I'm afraid I can't come up with any explanation of ~ for enter though.

[wofwofwof]

Anybody working on this? I really miss the option to use ALT and and CTRL. I use this keys to switch between my virtual screens.

I've just looked into the source. This change would require to refactor AutoTypeChar and then all AutoTypePlatformPlugins. There seems to be lots of work going on in the AutoType code so I hesitate to refactor it. Anybody planning to work here in near future?

cheers
wof

[droidmonkey]

You're welcome to fix this if you like.

[jwenz723]

I'm trying to understand what I would need to do to add the 'shift' functionality. Wondering if someone can tell me why this doesn't work:

https://github.com/keepassxreboot/keepassxc/blob/010d44eab7a84e457b6b72ef90c0f32d69511084/src/autotype/mac/AutoTypeMac.cpp#L318-L319

[droidmonkey]

Because shift is a key modifier (like CTRL, WIN/META, etc). It is sent to the OS in addition to any other keys pressed. Think of it this way, pressing shift all by itself does absolutely nothing (unless explicitly coded). You have to add another key to make it work.

[Simplenuity]

I've set my default Auto-Type sequence to
{CLEARFIELD}{USERNAME}{TAB}{CLEARFIELD}{PASSWORD}
and it used to work as expected.
I just realized that it meanwhile doesn't work anymore, i.e. both fields don't get cleared anymore.
Not sure if it's related to upgrading to 2.4.1 via ppa some time ago.

[radicarl]

Hello,
I need this too. In my case I have a form with
username
pin+token
password

The token is generated by a token generator and must be entered manual. My autotype should enter username, pin, password and the tab back (shift+tab) to the pin+token field. Without a working shift-modifier I have to select the field by myself

[OLLI-S]

I also recognized a missing Auto-Type code: {C:Comment}

In the documentation of KeePass Auto-Type (https://keepass.info/help/base/autotype.html) this code is not listed, but Dominik Reichl sent me the information by mail when I suggested a new feature.

The problem is that some websites (like Amazon or PayPal) have two different login masks:

• one where the username and the password is on one page
• one where the username and the password are on two different pages

Amazon and PayPal display still use these two different types (depending where you come from when you access these sites).

So in KeePass I have for Amazon and PayPal two different Auto-Type sequences.
When I am at the Amazon website and press the Auto-Type hotkey, then in the "Auto-Type Entry Selection" dialog of KeePass I can not see the full Auto-Type sequence (to differentiate the two sequences).

KeePass allows to enter a comment in the Auto-Type sequence:
{USERNAME}{TAB}{PASSWORD}{ENTER}{C:Felder auf einer Seite}
{USERNAME}{TAB}{ENTER}{DELAY 2000}{PASSWORD}{ENTER}{C:Felder auf mehreren Seiten}
The comments mean "Fields on one page" and "Fields on multiple pages"

In the "Auto-Type Entry Selection" dialog the comments are shown when you have set to see the column "Sequence - Comments":

Suggestion

Currently you show the following message when the syntax of the Auto-Type statement is not correct:

I suggest that you show the invalid part in this message, like:

The following statement in the Auto-Type statement is not correct or not supported:
{C:Felder auf mehreren Seiten}

This way users see what part is not correct/not supported.

I think it is not necessary to add a comment in Auto-Type (like in KeePass).
Otherwise I can add a issue for this suggestion.

[kvij]

I really need +{TAB} to work I have an application that puts the cursor in the password field. For the +{END} there is the {CLEARFIELD} workaround as long as there is no {PREVIOUS FIELD}

[sergeevabc]

Agggrrrhhh! O +{TAB}, where art thou?

[rzumer]

Is T-REPLACE-RX unsupported? Unfortunately I will have to go back to the official client if not, as I have a complex auto-type sequence for an application that has a non-standard input method.

[droidmonkey]

Is that even a documented thing?

[rzumer]

It's been for years. https://keepass.info/help/base/placeholders.html

[droidmonkey]

That looks unnecessarily complicated and will never be implemented.

[rzumer]

Thanks for addressing it, I suppose I will have to stick with the official Keepass client that supports auto-type in unnecessarily complicated applications.

[droidmonkey]

Can you explain your use case? There is probably better ways to do what you are doing.

[rzumer]

Like I said, it is for auto-type in an application that uses a non-standard input method. Without string replacement, I would have to mangle my username in order for it to be written correctly. I'm surprised that clients would choose not to implement part of the Keepass "specification" and forego compatibility with auto-type sequences written in the official client, but I respect the decision. For me this makes the official client more attractive because I don't have to write the wrong thing in my database just for auto-type to work as intended.

I also have a second string replacement tag in the same auto-type sequence in order to type a group name (required after the username) that I wrote in the entry notes for lack of a more suitable field. This keeps the note readable (no context otherwise) and lets me change the group in the notes instead of messing with the auto-type sequence.

[droidmonkey]

You should just put the mangled username in the advanced attributes along with your group name. Your sequence can simply reference those attributes using the {S:<attrname>} syntax. If anyone else on planet earth has a legit use for regex in autotype I'll eat my hat.

[rzumer]

That does not work either way because XC doesn't seem to be able to input the requested character so the username can be entered correctly, and it does not support key modifiers like %/Alt.

[droidmonkey]

Closing this as duplicate of several other, more specific, requests: #1825, #2633, #2215, #2603, #2350