Keepassxc: Copy attribute to clipboard for user added attributes doesn't work on KDE Plasma 5

[fourzerofour]

Copy attribute to clipboard function in the right click menu doesn't work for user added attributes, at least on KDE Plasma 5. The default attributes in the menu such as Title, Url and Notes, however, work fine without any problem

Expected Behavior

Data from user added attributes get copied to clipboard

Current Behavior

Nothing from user added attributes get copied to clipboard

Possible Solution

Steps to Reproduce (for bugs)

1. Add a custom attribute to an entry via Advanced tab in the entry's property.
2. Save the entry
3. Right click on the entry and in Copy attribute to clipboard menu, select the name of custom attribute you added just now
4. Observe that nothing is get copied to clipboard

Context

I use the attributes feature mainly for adding additional info that are related to the login details stored in an entry such as bank account, credit card number for the bank. Having them stored as attributes makes copying them much easier without many steps but this feature has been broken in the last few release of keepassx which then get carried over to keepassxreboot.

Your Environment

• KeePassXR version/commit used: 3f80134f07660c656e6f250f3921ccfebef5f335 (Oct 29)
• Qt version (e.g. Qt 5.3): 5.7
• Compiler (e.g. Clang++3.6.0): cmake 3.6.2
• Operating System and version: ArchLinux i686
• Desktop Environment: KDE Plasma 5.8

[droidmonkey]

Works for me on XFCE running Fedora 24. Please make sure your clipboard timeout setting isn't set to something really small.

[fourzerofour]

@droidmonkey Don't think it's related to clipboard timeout setting. Copying the default attributes in the menu such as Title, Url and Notes, however, work fine without any problem. It's just that ones I added myself are not copied-able.

[droidmonkey]

Anything special about those items? Unicode or special characters?

[fourzerofour]

Nah. They are just plain letters

[droidmonkey]

Hmmmm, request that you run this through the debugger to see where it is choking.

[droidmonkey]

This might be related to the appmenu-qt5 issue. Can you confirm if uninstalling appmenu-qt5 corrects this issue.

[fourzerofour]

It appears that I don't even have that installed. And I could only help with debugging if you provide me with instructions that I need to do beyond rebuilding kepassxc with debug

[fourzerofour]

Can someone else besides me with recent build of KDE Plasma 5 please try reproduce this?

[phoerious]

I can confirm this on KDE Plasma 5.8.5.

[stloewen]

Works for me.

Environment

System: KDE neon 5.8 (Ubuntu 16.04)
KDE Plasma Version: 5.8.5
KDE Frameworks Version: 5.30.0
Qt Version: 5.7.0
KeepassXC Version: 2.1.0 (AppImage and Snap)

[phoerious]

The reason for this behavior is again KDE's automatic accelerators. KDE adds & characters everywhere to allow you to use Alt+HOTKEY to trigger an action via keyboard. So when you have an advanced attribute called "foo", KDE makes something like "&foo" of it, so you can trigger that action with Alt+F.
There is no way for us to find out if that & is actually supposed to be there or was added by the KPlatformtheme. These auto accelerators also cause other problems throughout the user interface (you may sometimes see weird & symbols in database titles etc.

[phoerious]

You can work around this problem by adding this to ~/.config/kdeglobals:

[Development]
AutoCheckAccelerators=false

I've added an entry to our FAQ: https://keepassxc.org/docs#faq-kdeaccelerators

[fourzerofour]

Thanks a lot! The workaround totally fixes the issue for me

[droidmonkey]

Closing due to valid workaround (also, this is a KDE issue).