When first opening the 1PW Browser Extension in Chrome, I've had several occasions when there are two seemingly active text input fields being shown simultaneously, each with a blinking cursor. One input field is typically the username or password field prompt of the webpage that I've manually navigated to. The other input field is the "Enter your Master Password" field in the login window of the 1PW Browser Extension. Obviously at this point I want to type in my master password, but it's difficult to tell which field actually has the UI focus until I start typing (and thereby risk entering several characters in the wrong field by accident) or take time to physically click inside the Master Password field every time. As a suggestion, can the login window for 1PW make it visually obvious that the "Enter your Master Password" field has the UI focus? Perhaps a bold colored outline around the input field when it has focus?

Comments

The issues you're describing are something that doesn't happen to 98% of our users nor can we ever reproduce it. We've done remote sessions with customers and it didn't show up there.

Do you have a trackpad/touchpad?

As a suggestion, can the login window for 1PW make it visually obvious that the "Enter your Master Password" field has the UI focus? Perhaps a bold colored outline around the input field when it has focus?

We cannot do this. We have tried several times in the past but Windows tells us that 1Password mini is always "focused" when it clearly isn't. The problem is, without Windows giving us the right information, it is difficult to prevent false positives. If we could just reproduce it, we could find a solution and/or talk to Microsoft about a potential Windows issue.

Here's what it looks like when it is not focused by force in the code:

Everyone have this same code, it is supposed to be completely grayed out when it is not focused.

I've had several occasions when there are two seemingly active text input fields being shown simultaneously, each with a blinking cursor.

This is not supposed to be technically possible, the OS is supposed to prevent this type of issue.

Yep, I've actually spent nearly a whole week on trying to break this on various machines including virtual machines, various Windows versions and various 1Password versions, I found a few but we've resolved it since. It didn't resolve everyone'e issue.

What's concerning is that we are not finding any patterns either when we get reports of this, there's one report here who said that two-finger drag to scroll and pinch to zoom settings break this in 1Password. We couldn't reproduce this even with identical hardware and our code is not involved in these two settings. You can try it to see if it helps at all.

I have the same issues, on multiple devices, since many versions (7.2.576 atm), that led me to send my masterpassword to a site instead of to 1pw multiple times now.

The issue seems to be related to the Auto-Lock after x minutes for me.
If the AutoLock Timeout has run out and I invoke 1pw via chrome plugin, I can see the available entries for a brief moment, then the "closing" animation runs down and the master password field shows a cursor but key entries get thrown into the last focused html field.

Yes, I do have a touchpad on my Surface Book and have run into this issue sometimes. Nowadays I always look at the screen before I start typing the masterpw so that it doesn't appear in a username field and being shown as cleartext...
BTW: One more reason why I'd love to see secure desktop for unlocking

It happend again today, but sadly I was not able to screenshot it. (Went away when opening the snippingtool).

I had Cursors blinking in both the logins Input field and the master password Ínput field.
I was not able to reproduce it right after it happened though.

I'm pretty sure this is some kind of timing issue with the autofocus of the Login field, incredibly hard to get "just right" and therefore not really reproduceable at all.

Maybe it would be a suitable workaround to have a periodical regain of the focus for the master password field?
Or some kind of warning, if you start typing while the 1pw Window is open but does not have the focus?

My personal workaround is that I launch 1pw right after first login to Windows so that if I lock the PC and unlock it all I have to do to activate the extension is to look into the PC’s camera - kudos to Windows Hello

If the AutoLock Timeout has run out and I invoke 1pw via chrome plugin, I can see the available entries for a brief moment, then the "closing" animation runs down and the master password field shows a cursor but key entries get thrown into the last focused html field.

That's a glitch in Windows Presentation foundation (WPF), we've also spent a lot of time on trying to fix it; it refuses to invalidate/flush the UI cache when we tell it. We don't have a replacement for WPF but we'll keep hunting.

I have a feeling this glitch or something in the related area is what could be causing the focus issue here as well. The only problem is, we've seen this in 1Password 4 and it doesn't use WPF.

The way we focus 1Password mini is something that Windows do not permit by default, so we have to force it in odd ways. There is no official support for focusing a UI out of nowhere if the user did not invoke it. When you click on 1Password icon within Chrome, you're not focusing 1Password, you're focusing the extension, which sends a call to running 1Password process to bring up its UI. That's something that Windows do not permit.

That's why it happens far less if you use the keyboard shortcut instead.

1Password X extension has no problems with this because it's self-contained and has its own UI. Unfortunately, as much as we'd like to, 1Password X cannot work with standalone vaults, only with 1Password.com accounts.

Or some kind of warning, if you start typing while the 1pw Window is open but does not have the focus?

That's what we did, you can see the grayed out window screenshot above in my first reply. It didn't work because Windows tell us that the view is focused, which is insanely wrong as we can see typing in other view with cursor blinking.

The problem here is that Windows is giving us wrong data and we can't reproduce it, we need to reproduce the issue with our debugger running, so we can see why Windows or our program is wrong. Every time we did a remote session with a customer, it didn't happen, which is likely due to remote session itself causing some data to reset.

lol! I thought you guys were Canadian and far too polite for that sort of thing without beer being involved, ey? But I did notice it does still happen, though this time, the focus was grabbed by the address bar in the browser (chrome, latest). Just another frustrating data point. I really would be OK, with running some kind of debugger for you guys on this issue if it would help.

Most of us are actually outside of Canada. I'm near Seattle in US and Serg is in Canada. I was mostly raised in Brooklyn before moving to Washington, that would explain my desire to punch that guy. We're both Russians, so it's normal to us.