Keyboard Input Lag When Unlocking Extension

[EliasMarine]

Steps To Reproduce

1. Go to Chrome/Brave BW extension
2. Click on BW extension to open & unlock with a pin
3. Input unlock pin

Expected Result

The BW extension should accept keyboard input without any lag.

Actual Result

The BW extension has about a ~2-3 second lag before it accepts keyboard input.

Screenshots or Videos

No response

Additional Context

When attempting to unlock the BW chrome extension, there is about a ~3-second lag between when the extension dropdown opens to when it accepts keyboard input.

Before the 2022.9 update, I never experienced this lag. In version 2022.8 and older, I would click the extension, and it would start taking input instantly. Looking back at this, this was an unnoticed workflow enhancer, as the vault would unlock pretty quickly.

I'm running the BW extension on Brave Beta Version 1.44.86 Chromium: 105.0.5195.127 (Official Build) beta (arm64). This shouldn't matter as I've always run Brave in beta and the BW extension worked flawlessly before 2022.9. & 2022.9.1.

I created a new Brave beta profile to test, but still the same thing.

I am not using a self-hosted instance.

All my browsers are up to date.

Once browsers were closed out, there were no lingering processes for Brave or Chrome browsers.

I ran the extension on Chrome Version 105.0.5195.125 (Official Build) (arm64), and I still get the same input lag issue.

I tried on safari, Version 16.0 (17614.1.25.9.10, 17614) and input lag is also present there.

Operating System

macOS

Operating System Version

Version 12.6 (21G115)

Web Browser

Brave

Browser Version

Brave Beta Version 1.44.86 Chromium: 105.0.5195.127 (Official Build) beta (arm64

Build Version

2022.9.1

[EliasMarine]

Other users are also experiencing this issue:

https://www.reddit.com/r/Bitwarden/comments/xicwem/slow_keyboard_input_when_unlocking_bw_chrome/

[Davidencho]

I also have this same problem with the normal unlock password

[mrlinuxfish]

I'm having the same issue. Clicking on the password field appears to allow pin entry faster than waiting

[valepakh]

Same here, latest Chrome Version 105.0.5195.127 (Official Build) (64-bit) on Windows, Bitwarden extension version 2022.9.1

[mrlinuxfish]

I'm still having the same issue on the newest 2022.9.1 update. Chrome Version 105.0.5195.127 (Official Build) (64-bit)

[tangowithfoxtrot]

Hi @EliasMarine. I've marked this issue as being consistently reproducible in our internal bug-tracking system. Thanks for reporting!

[mdavis6890]

I think this needs to be considered a minor security issue, since those lost keystrokes are going somewhere. So the first few characters of your passphrase are being entered into whatever had the focus. Or can we say for sure that the BitWarden extension itself has the focus, in which case it's probably not so bad.

[bendem]

Same problem on edge 105.0.1343.50, windows 10.

[jikamens]

👍

[HighMans]

Having the same issue here on Chrome v.105.0.5195.127, Bitwarden v. 2022.9.1.

[jberkenbilt]

For what it's worth, I also see this behavior using the desktop client installed with snap on Xubuntu 22.04. I notice that the prompt appears just after this:

(node:97813) UnhandledPromiseRejectionWarning: TypeError: Cannot read properties of undefined (reading 'setContextMenu')
    at TrayMain.updateContextMenu (/snap/bitwarden/76/resources/app.asar/main.js:48772:23)
    at MessagingMain.updateTrayMenu (/snap/bitwarden/76/resources/app.asar/main.js:50734:28)
    at MessagingMain.onMessage (/snap/bitwarden/76/resources/app.asar/main.js:50668:22)
    at MessagingMain.<anonymous> (/snap/bitwarden/76/resources/app.asar/main.js:50659:151)
    at Generator.next (<anonymous>)
    at /snap/bitwarden/76/resources/app.asar/main.js:50638:71
    at new Promise (<anonymous>)
    at messaging_main_awaiter (/snap/bitwarden/76/resources/app.asar/main.js:50634:12)
    at IpcMainImpl.<anonymous> (/snap/bitwarden/76/resources/app.asar/main.js:50659:79)
    at IpcMainImpl.emit (node:events:526:28)
(node:97813) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)

Shortly after, there's this:

13:34:42.880 › TypeError: Object has been destroyed
    at WindowMain.<anonymous> (/snap/bitwarden/76/resources/app.asar/main.js:49157:36)
    at Generator.next (<anonymous>)
    at /snap/bitwarden/76/resources/app.asar/main.js:48971:71
    at new Promise (<anonymous>)
    at window_main_awaiter (/snap/bitwarden/76/resources/app.asar/main.js:48967:12)
    at WindowMain.updateWindowState (/snap/bitwarden/76/resources/app.asar/main.js:49152:16)
    at WindowMain.<anonymous> (/snap/bitwarden/76/resources/app.asar/main.js:49106:28)
    at Generator.next (<anonymous>)
    at /snap/bitwarden/76/resources/app.asar/main.js:48971:71
    at new Promise (<anonymous>)

If you run the bitwarden desktop client from the command-line in this environment in a way such that the output is not discarded, you can actually see the exception thrown right after the delay period, after which the input field starts accepting keyboard input.

[SuzukiStumpy]

Also having the same issue using Chrome extension 2022.9.1 on Chrome 105.0.5195.128 (Official Build) (64-bit) (and other recent builds - it's set to auto-update so always running latest). Both on Win10 and Win11 (different machines). Bitwarden account is hosted by Bitwarden.

Only started happening with the update to 2022.9.x version of the extension, before that was running fine.

[basrieter]

Same here on Chrome (Version 105.0.5195.127) with BW (2022.9.1). Very annoying.

[pabuisson]

It looks like it hasn't been confirmed outside Chrome-based browsers so here I am. I'm also having the exact same problem in Firefox:

• Reproduced in Firefox 106b and 107a
• Bitwarden version 2022.9.1

[bilogic]

Can revert to an earlier version of extension for now?

[ishanjain28]

I am also on firefox 105 and bitwarden 2022.9.1 and this is a issue for me as well.

[ishanjain28]

Rolled back to 2022.8.0 by visiting this page, https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/versions/ and this version works perfectly.

[bilogic]

Is there a way to rollback on Chrome? Which is the culprit actually? Server or browser extension?

[jijijaco]

Same issue on my side (delay for the input). Now I always end up entering a wrong password because the first letters are missing...
I use Chrome and Brave. Same issue with both.

[Camusensei]

Same for me on firefox (linux & windows) and edge. I think it's safe to assume it's a bug introduced with version 2022.9.1 which was rolled out a few days ago?

[trygveaa]

I bisected this issue and found that it was introduced in commit 0eda418 from PR #3207.

[trygveaa]

@cyprain-okeke: I see you're the author of that PR, can you take a look at this issue?

[cyprain-okeke]

@djsmith85 has reverted with this PR #3608 and we are moving to QA to testing

[djsmith85]

Hey everyone, thank you all for your detailed reports and patience on this getting resolved.

A fix has been made and will be included in the next release (2022.10).

Kudos to @trygveaa to spotting the underlying issue. I also just found that shortly before your comment.

[flashcode]

Hi,

Is there somewhere a nightly build of the extension for the affected browsers, that we could test and give feedback, to be sure the issue is actually fixed?

[djsmith85]

Hi @flashcode thank you for your interest in testing this.

We don't offer nor support nightly builds at this time. We do use build pipelines powered by Github Actions though, on our PRs/branches. If you are really curious you could grab one of the build artifacts from here.

I recommend using those build artifacts only for testing purposes! This is a pre-release and might have other issues.

[trygveaa]

FWIW, it was pretty easy to follow the instructions on https://contributing.bitwarden.com/clients/ to build the extension and load it unpacked in Chrome.

[bilogic]

@trygveaa did the new release solve the issue? like @flashcode , wanna be sure the issue is actually fixed. :)

[OliverPearmain]

@trygveaa did the new release solve the issue? like @flashcode , wanna be sure the issue is actually fixed. :)

I've not been able to tell, because it seems impossible to lock the vault, despite timeout settings or explicitly using the "lock now" action 😬 🤦‍♂️

Regardless, I've just check the extension versions and it doesn't look like there's a new release available anyway (at least on Firefox). I'm still on 2022.9.1 which was the version with the problem.

[bilogic]

@OliverPearmain to test the fix, one would have to build and load the extension unpacked in Chrome.

[OliverPearmain]

@OliverPearmain to test the fix, one would have to build and load the extension unpacked in Chrome.

👍 thanks, I think coz you said "new release" I assumed there was an official new version released. I'll wait.

[bilogic]

Oops, it should have been the new commit/fix

[flashcode]

@bilogic: the issue seems to be fixed, but I was unable to make a complete test because for an unknown reason the key binding Ctrl+Shift+L was not working (I tested under Chrome).
But when clicking in the extension to unlock it, it seems the focus in the field is instant.

[bilogic]

Thanks @flashcode good to know!

[trygveaa]

@trygveaa did the new release solve the issue? like @flashcode , wanna be sure the issue is actually fixed. :)

Yup, works fine in master.

[webdev69420]

I also confirm the issue is fixed!

[flashcode]

I also confirm the latest released version 2022.10.0 definitely fixes the problem (tested in Chrome 106.0.5249.119), thanks for the fix!

[sir-pinecone]

Just did a quick test using Firefox and the password field gains focus in version 2022.9.1 and stops gaining focus in 2022.10.0. I also tried the very recently released 2022.10.1 and that also has the issue.

Edit: apologies, I didn't notice that this issue is for unlocking, whereas I'm talking about logging in.

[djsmith85]

@sir-pinecone: Multiple people have confirmed this is working. If this is occuring only on log-in then please have a look at #3800. This issue only occured on the lock screen when unlocking.