Add copy password button to Edit Entry dialog

[amandabee]

In KeepassX if I open an entry for editing, say to add the URL, I can still right-click and copy the password without exposing it. In XC I'm not able to do that. I either have to close the edit window or expose the password.

Expected Behavior

right-click menu in Edit Entry dialog should include "copy password" (and "copy username" tbh). So should the preview/overview of the key.

Current Behavior

The right-click menu only includes undo/redo, cut/copy/paste/delete and select all. If I select a password that's hidden, all but "delete" and "select all" are greyed out.

If I don't open a key, there's no right click behaviour at all on the bottom half of the screen. I can select the username and right-click to copy it, but I have to right click on the entry in the list above the overview/preview pane to copy the password.

Possible Solution

Add "copy username" and "copy password" to the context menu in the Edit Entry dialog and the overview/preview of each entry.

The preview pane should include the full context menu that's available in the search results.

Context

I often want to view the details of an entry to confirm that it's the one I'm looking for, so I double click or enter after a search, which brings up the edit window. Once I'm in the edit window if I want to copy the password over without showing it to my colleagues who are all unrepentant shoulder surfers, I have to cancel and then use the "copy password" option in the right click context menu. It would be really helpful if it was available anytime I'm viewing or editing an entry.

I've been using KeepassXC for a few weeks and I thought I'd eventually get used to it but it's absurd how often I have to take that extra step to get the password into my clipboard without showing it to the world.

Debug Info

KeePassXC - Version 2.3.3
Revision: 0a155d8

Libraries:

• Qt 5.9.5
• libgcrypt 1.8.1

Operating system: Ubuntu 18.04 LTS
CPU architecture: x86_64
Kernel: linux 4.15.0-24-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

How come viewing the extended attributes in the main view and double clicking the password cell or pressing CTRL+C on the specific entry doesn't work for your workflow?

[amandabee]

I actually didn't know double clicking was an option.

But it is awkward that I can only get it from the search results and it's not available in the obscured password in the preview pane or the edit pane.

Often I've opened it to edit because the browser plugin isn't recognizing the URL (because it has changed or because it's not there) and so I want to update the URL and log in.

It isn't the end of the world but it has annoyed me for several weeks, enough that I finally decided to file an issue. I'll probably eventually train myself to get the password from the search results list, but it would be convenient if I could get it from the preview pane and edit window, too.

[droidmonkey]

Certainly not disputing the value of a little clipboard icon you can click to copy the password.

[oittaa]

Yeah this is a pretty huge problem that bit me in the ass. You create a new entry for a new site and generate a random password and then CTRL+C the hidden password and CTRL+V it to the password field on the site or whatever, but you actually paste what was in your clipboard before doing any of this! CTRL+C did nothing!

Fields that are selectable should be copyable. ALWAYS!

[droidmonkey]

Its actually very common (if not standard) to NOT allow you to CTRL+C a hidden password field. Try to do that in your browser.

[oittaa]

It's a known bug in Firefox. Chrome and Safari will let you copy.

EDIT: And it's super unintuitive have a different behavior than in KeePass 2 and KeePassX.

[droidmonkey]

What? That issue is totally irrelevant to this discussion. That has to do with disabled fields, not password fields. You are also totally incorrect about being inconsistent with KeePass2/KeePassX.

[oittaa]

Seems like I was a retard and remembered the behavior incorrectly from KeePass2/KeePassX.

Doesn't change the fact that I hate fields that are selectable, but not copyable. ;)

[phoerious]

The only thing I hate are password fields that actually copy the bullets.

[amandabee]

I think that @oittaa is describing a slightly different issue. I've settled into doubleclicking the password in the list to select it. But it would still be helpful if there was any way at all to grab the password (without exposing it) from the preview pane and the edit entry dialog.

[nicad]

I also believe we should be able to copy hidden passwords, the entire reason we go into the password manager is to copy passwords. Ironically because of this behavior I never assumed I could just do CTRL-C in the search view to get the password and only discovered that recently. (arguably it's inconsistent, I don't reveal the password and yet I can copy while if I select an entry I can't copy the password ...)
It's probably another issue but another behavior that doesn't make sense to me: hide by default the password being generated.
Commercial software like 1Password and Dashlane reveal what just got generated, 1Password also reveal on click while editing. It also allows to save when editing an item. All these behavior made perfect sense. KeePassX(C) always felt foreign usability wise (I've been using it for many years).

[tomhundt]

So, the thing that always gets me is the inability to use shortcuts (such as Cmd-U, open URL) while in the detail window (editing an entry). Often, I'm creating a new entry and want to test it out, whether I've found the right login URL, or the autotype customizations, for example. Yes, there's the "how do you handle the Cmd-C Copy shortcut" issue, and I would answer "if focus is on some field, use as normal -- copy the selected text, if any -- else if focus is on the window itself (no cursor visible) then copy the password, same as if the entry was selected in the summary/main view". That seems reasonable to me. (It's also why, I assume, the shortcut used to be Shift-Cmd-C. That would be fine for this purpose, also.)

You can get to the "focus is on the window itself, not on any field" state by clicking on the window's background, where the field labels are, and apparently by hitting Shift-Tab twice after opening an entry (cursor on Title field). BTW this may be unintentional, I was able to make it crash once by fooling around with this, and just now noticed I'd broken the unlock pw ("master key") input on my other files (other tabs). So there may be obscure bugs lurking around here.

Thanks for telling us about the double-clicking in summary view, I didn't know about that one, either.

I would use a "Copy the password" icon if it were available. But still want the shortcut :-)

Thanks

[derula]

if focus is on some field, use as normal -- copy the selected text, if any -- else if focus is on the window itself (no cursor visible) then copy the password, same as if the entry was selected in the summary/main view

I think I have to disagree with this one. This seems really inconsistent, possibly even prone to leading to different behavior on different platforms.

As was mentioned before, it is standard behavior that Ctrl+C (or right click to copy) doesn't work on password fields. Changing this seems hack-y and counter-intuitive.

Ctrl+C copies when no field has focus? ...I don't love it. Especially if you disallow Ctrl+C on the password field, this would be inconsistent and weird.

I would far prefer to just have a "copy password" button next to the password field in the edit dialog. If necessary, a separate keyboard shortcut could be added to always copy the password, regardless of focus.

Regarding the original workflow problem, I can say that I would occasionally make the same mistake. A "copy password" button would be a sufficient solution for me - even though I don't mind using Esc + Ctrl+C instead.

Alternatively, would it be possible to change what the Enter key does if the search field has focus? It could just copy the password instead of opening the edit view. This would solve OPs problem very elegantly. Pressing Enter could still open the editor if the list view has focus.

As a side note, I often find myself double-clicking the list view expecting it to open the edit view. I never even realized that double-clicking it would copy the clicked cell instead. As double-click "didn't work," I didn't even bother trying Enter and just went for the context menu; double-click and Enter doing completely different things seems odd to me.

Just my 5 cents, I hope I can provide some insight into a user's perspective / workflow, I mean no disrespect. I acknowledge that a lot of care most likely was already taken when considering possible usage patterns, and I appreciate the amazing work this project is doing. Keep it up!

[WofWca]

Hey. I think the supposed resolution should be revisited.
The most obvious alternative IMO is to add a "copy" button against the password field in the "Edit / Add entry" screen, much like in the "generate password" windows.

The problem with #3641 is that

• As the description says:

  Note: unsaved changes to the entry will not be copied to the clipboard.

  This is crucial, and is unexpected, especially for the "Add Entry" dialog, because, well, the password is empty there, so the button is actually of no use.
  The way I usually use it is create a new entry while registering on a website, so yeah, I need to copy the freshly generated password. I know I can do that from the "generate password" window, but I don't always generate the password at the same time I need to copy it.

• The button is far away from the actual password so it's not intuitive to look for it there.