Missing Visual Focus on "Enter your Master Password" Field in 1PW Browser Extension

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?


1Password Version: 7.0.540
Extension Version: 4.7.0.90
OS Version: Windows 10 Build 16299
Sync Type: Not Provided

Comments

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @ArcTangent,

    Thanks for reporting this.

    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.

  • Thanks for the detailed and quick reply @MikeT.

    Sounds like the team has expended significant effort trying to track this down already. I didn't notice the relevant past threads on the forum :(

    No, I don't have a trackpad/touchpad on this system.

    For what it's worth, I think the current design of the not-focused window per your screen capture is fine.

    Agree with you that seeing two active input fields simultaneously shouldn't happen. Must be one of those weird OS "gotcha's" that defy efforts to track down.

  • MikeTMikeT Agile Samurai

    Team Member

    You're welcome.

    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.

  • Hey ArcTangent, hey MikeT,

    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.

    I'll try to attach a screenshot, once it happens again.

  • sniemsniem
    edited September 23

    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 :)

  • MikeTMikeT Agile Samurai

    Team Member

    Hi guys,

    @fealXX,

    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.

    @sniem,

    BTW: One more reason why I'd love to see secure desktop for unlocking ;)

    It wouldn't help, we actually had reports of typing not working in secure desktop for 1Password 4 because of Windows 10 updates. You had to click into the password field to focus it.

    We have two separate technology stacks in 1Password 4 and 1Password 7, two separate codes as how it all works and yet, both versions had the same inconsistent/rare reports of this.

    Yes, I do have a touchpad on my Surface Book and have run into this issue sometimes.

    Serg has a Surface Book and I have Surface Pro 4, we saw it max 3 times in 2 years. Of course, without our debugger running. :angry:

  • fealXXfealXX
    edited September 24

    @MikeT so it is confirmed that 1password X does not have that issue? I only have a family vault and one from work, both cloudhosted at 1pw.com, so a switchover would be possible for me, right?

    Edit: Just tried it, installed, works fine. I'll just hope it does not happen again.
    Is there any problem with having the desktop and the 1pw X both installed?

    Thanks for the insights.. :)

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @fealXX,

    Yes, there's no focusing involved for the 1Password X because Chrome owns it completely.

    No problem having both 1Password X and desktop app enabled at the same time. We actually hope to have them unlock each other if securely possible in the near future.

  • I am part of the 2% lol, and it is just funny how this issue is so elusive. One day you guys will find a stray tuple or something in the code.

    https://discussions.agilebits.com/discussion/comment/424574

    I don't even fully know if it is still happening to me since I think I just make sure I see where the password text is going.

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @AlwaysSortaCurious,

    If it is as simple as a stay tuple or silly typo, I will punch Serg (our head Windows dev) in the face for you.

  • 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.

  • MikeTMikeT Agile Samurai

    Team Member

    Meh. :sarcastic:

    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.

  • That i understand, as a Greek, and a Bronx Boy... which also explains this latent anger i never quite understood. Brooklyn, its all clear now!

  • brentybrenty

    Team Member

    I was in Brooklyn long enough to get a but a glimpse of this phenomenon. :crazy:

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file