Dangerous UI bug deletes (now "Archives") entries without intent and without confirmation

Dan_Aykroyd

Hey,

Just now I stumbled on an UI issue that I catched, from the side of my eye, deleting (now "archiving") the entry on top of the list. I was making a search on the search field and, when wanting to delete what I typed, I've pressed Command+delete; the ubiquitous macOS key combination to delete the whole line where the user cursor is. Instead, it deleted the first entry of the results; even when out of focus.

Here are the steps to reproduce:

• Go to any of your Vaults, press Cmd+F to start the search
• Type any string

• Press Cmd+delete to delete the line you just typed and where you are focused. Instead of that, you will see the first item entry on top being deleted

• !!! - Notice how the blinking cursor is on the search field (focused) and how the first entry of the result is unfocused (gray instead of blue). Still, the Cmd+delete action is being processed as a delete (archive) function, instead of the standard "delete the whole line where I'm typing" macOS behavior and where the user is currently focused

• !!! - Notice how there is no confirmation that anything was deleted (archived), since I remember when Cmd+delete, you suppress the warning. If the user wasn't paying attention he/she could be deleting (archiving) things without noticing.

Hope you are able to check this and fix it soon. Thanks!

---

1Password Version: 7.8.4
Extension Version: N/A
OS Version: macOS Big Sur
Sync Type: 1Password

ag_ana

Hi @Dan_Aykroyd!

!!! - Notice how there is no confirmation that anything was deleted (archived), since I remember when Cmd+delete, you suppress the warning. If the user wasn't paying attention he/she could be deleting (archiving) things without noticing.

I have tested your steps, and this is what I got when I used the Cmd+Delete keyboard shortcut:

For confirmation, have you clicked on the "Don't ask this again" checkbox?

Dan_Aykroyd

Thanks @ag_ana for your reply.

Yes, I have that box checked; that's why I don't get any confirmation. But if I still had an older version of the client, before you introduced the Archive, Cmd+Delete sent the item to Trash without prompt (if I recall correctly).

In any case, the issue is that the entry is being actioned upon, while the user is focused (and typing) on the search box. I would understand it as a functionality, let's say, if you want the user to be able to act on the first entry on top while searching, but trying another command, such as Cmd+C (to copy the entry password; following that logic), gives the "invalid keypress" ding sound, and it doesn't act upon the entry.

As a design principle, it's not well conceived to have two elements focused at the same time (the search box to type and Cmd+ to act upon an unfocused; grayed out item entry). This is the standard behavior across all main OSes. Just try this in Finder search, or any other app that you might have, and you'll see what I mean; search results remain unfocused and don't get actioned upon while the user is entering commands on the search box (e.g. Cmd+Delete doesn't delete a file when focused on Finder search field).

Thanks.

ag_ana

Thank you for the clarification @Dan_Aykroyd! I have passed your feedback to the team to see what they think about this :+1:

nickey239

I also had this issue, I use command-delete all the time and expect it to delete the text behind my cursor.

ag_ana

Thank you for chiming in on this as well @nickey239 :+1:

mlavigne

I'm also having this issue. I have the same expectation when using CMD+DELETE. As a result of that expectation, I noticed I had sent a bunch of passwords to the new Archives section by accident. Clicking CMD+DELETE when the Search field is focused should only delete text in the focused Search field. Thank you in advance for looking into this issue.

ag_ana

Thank you as well for the feedback @mlavigne :+1:

rmgn

OP put it perfectly. I'm having precisely the same issue here, with the same habit of cmd+delete to delete the whole line.
Is there a way to "uncheck" the "don't ask again" box somehow? I can't find it anywhere.
I'm ok even if you point me to the .plist file or something.
Thanks

rmgn

ping @ag_ana

rudy

@rmgn,

if you remove ArchiveSuppressConfirmationAlert from the preferences plist by running this command in terminal it should make it prompt again:

defaults delete com.agilebits.onepassword7 ArchiveSuppressConfirmationAlert

rmgn

@rudy That didn't work. I ran the command it while 1p was open, tried archiving an entry, no confirmation.
I quit 1p, tried running it again, and got an error this time:

2021-11-23 10:44:10.934 defaults[33122:13041274]
Domain (com.agilebits.onepassword7) not found.
Defaults have not been changed.

I then opened 1p, tried archiving, no confirmation.
I ran the command again while 1p is open, and got the same error.

rudy

@rmgn,

are you using 1Password 7?

rmgn

@rudy Yes. The first time I ran the command it worked (but the app still doesn't confirm archive). Maybe mac is showing that error when the option name doesn't exist. Auto-complete doesn't show it anymore:

rudy

@rmgn,

I bet its also in ~/Library/Group Containers/2BUA8C4S2C.com.agilebits/Library/Preferences/2BUA8C4S2C.com.agilebits.plist if you manually edit it from that file you'll want to also killall cfprefsd for the change to take effect

rmgn

@rudy I do see ArchiveSuppressConfirmationAlert_ in that file, however when opening it in vscode, it looks unstructured and contains binary data. In my experience editing files like that as text results in some unpredictable behavior.
Are you sure I can just delete that from the line?

rmgn

I got a reply from support, this worked:

defaults write ~/Library/Group\ Containers/2BUA8C4S2C.com.agilebits/Library/Preferences/2BUA8C4S2C.com.agilebits ArchiveSuppressConfirmationAlert false

ag_ana

Thank you for the update and for sharing the command with the community @rmgn!