Minor bug: Password fields does not have focus when unlocking the vault for the first time.

Options
SixFive7
SixFive7
Community Member
in Desktop betas (Mac, Windows, and Linux)

After rebooting the computer and using 1password the first time one gets the prompt to unlock the vault first. However, on this window the password prompt initially does not have focus. This means you need the mouse to click before you can start typing. Breaking the otherwise awesome keyboard only flow v8 provides.

1Password Version: 8.2.2
Extension Version: 2.1.0
OS Version: Windows 11 (21H2 build 22000.194)

Comments

  • Jack.P_1P
    Jack.P_1P
    Options

    Hi @SixFive7:

    Neither a colleague of mine or myself were able to replicate this on Windows 11. Would you mind walking through some more specifics of what you were doing to see this issue?

    Cheers!

  • SixFive7
    SixFive7
    Community Member
    Options

    Hi,

    These steps allow me to replicate the issue:

    • Make sure you bind "Show/Hide Quick Access" to "CTRL + ALT + \".
    • Quit 1password.
    • Start 1password.
    • Observer how the focus is correctly on the password prompt.
    • Do not log in, instead close (not quit the app).
    • Go to notepad.
    • Press CTRL + ALT + \ to open quick access.
    • Observer how the focus is **not **on the password prompt.
    • Now you need to touch the mouse to continue.

    I hope this helps.
    Kind regards

  • Jack.P_1P
    Jack.P_1P
    Options

    Hi @SixFive7:

    Thanks for getting back to me with some detailed reproduction steps. However, neither myself or a colleague were able to replicate this issue using your steps, as seen here:

    Is it possible you have an application running that would be stealing focus from 1Password?

    Jack

  • SixFive7
    SixFive7
    Community Member
    Options

    Hi,

    I figured out the source of the issue. If you change the binding to CTRL + ALT + \ the 1Password app reacts to the still pressed ALT key by shifting the focus to the hamburger menu. Pobably triggered by the ALT Key_Up generating a default WM_MENUSELECT window message.
    A fix would be to either ignore that window message if ALT is part of the shortcut. Or better yet; always ignore that window message and listen for the ALT key directly, but only if 1Password observes the Key_Down as well as the Key_Up -> as the Key_Down happens outside and before 1Password is activated in case of a key binding containing ALT.
    Should be an easy fix :-)

    Attached a gif where I press the CTRL + ALT + \ key combo to get into the bug. But then afterwards also press the ALT key a few times to show how it happened.

  • Jack.P_1P
    Jack.P_1P
    Options

    Hi @SixFive7:

    Thanks for the detailed steps on that. I was able to replicate this issue fairly consistently, but not 100% of the time. It seems like what causes it is not releasing ALT until after 1Password opens up and is asking for your password. If I quickly release all the shortcut keys, I don't see this happen.

    I'll file an issue internally to see if it's possible for us to ignore the key up event if we don't have a key down event.

    Thanks!

    ref: dev/core/core#10448

This discussion has been closed.