clients
clients copied to clipboard
bitwarden
Problem with dropped letters/keypresses when Searching vault from Browser extension (debounce)
Steps To Reproduce
Environment
- Bitwarden 2022.6.x
- macOS 12.4
- Chrome 103
Repro
- click on bw icon in Chrome toolbar to open vault
- start typing a search word— type fast
- notice that midway through your typing, the field drops letters or garbles part of the word by overwriting the first few letters (this happens precisely when the preview/results area refreshes)
This might be a little hard to reproduce, but if you have a large enough vault (1000+ items) it shouldn't be too difficult.
I think this is a debounce issue. The search function seems to run in a tight loop. It should run synchronously, and not drop keypresses so if typing quickly the search term is entered correctly.
Expected Result
Search term e.g. "google" is entered completely
Actual Result
Search sometimes gets entered as "goole" or "gogl" etc. due to dropped letters during refresh of results.
Screenshots or Videos
No response
Additional Context
No response
Operating System
macOS
Operating System Version
12.4
Web Browser
Chrome
Browser Version
103.0.5060.114
Build Version
2022.6.3
Thanks for submitting a ticket! I am having a hard time reproducing the level of fastness needed for this. Can you use Quicktime to attach a screen recording?
@ginat in a Vault with ~1400 items (from collections), I need to at least type at a speed of ~60WPM or 300CPM to reliably reproduce this issue. Sometimes, even slower typing speeds can cause this problem.
Environment
- Fedora 35
- Firefox 97.0.1
- Bitwarden plugin 1.56.6
I'm having a hard time capturing it in a screen recording @ginat
It occurs during the initial vault load after a "cold start" of the browser. Once the cache is warmed up, it's much harder to reproduce. When you first start typing in the search box, the extension seems to wait for you to pause typing (around ~250ms) and then will trigger the vault to load. It's during this loading that keypresses are eaten (you see the spinning arrows while it's loading/decrypting).
I think this would be solved by simply performing that "expensive" load/decrypt operation when the extension does its initial load instead of upon first use of the search field.
Just adding my anecdotal experience with this issue, it's frustrating to say the least but not show stopping.
Ubuntu 20.04 on a modern desktop, seeing this occasionally on both Google Chrome and Firefox, current versions below:
- Google Chrome Version 99.0.4844.51 (Official Build) (64-bit), Bitwarden Version: 1.56.6
- Firefox 98.0 (64-bit), Bitwarden Version: 1.56.6
As noted by karlgrz above, this issue still persists in v 1.56.6 of the extension. Is there a timeline for when this issue will be resolved? This is pretty much the first material problem I've ever experienced w Bitwarden, all previous issues I've had over the years have been 'gripes' about UI decisions and whatnot. This one is an actual bug that causes genuine frustration...
Still an issue with version 1.57.0 on Firefox 99 *Update 20220627 - still an issue with version 2022.5.0 on Firefox 101.0.1
Still a problem with 1.58.0 on Google Chrome Version 100.0.4896.127 (Official Build) (arm64) on M1 MacBook Pro.
I often have to backtrack and fill in one or more missing characters in the search, that were dropped/ignored as I typed.
So I finally managed to capture a good example of this bug in a screen recording. It seems like it doesn't really depend on how fast you type, but rather how many keypresses fall into the window where the extension does something in the background as mentioned by @luckman212. For me, this doesn't only happen after a cold start, but for every first search when opening Bitwarden as shown in the attached video. When I close this view, the problem will occur the next time I open Bitwarden and do a search.
https://user-images.githubusercontent.com/48023919/165590563-a5dda758-31f2-4570-961f-a453d65f7a7d.mp4
Environment
- Fedora 35
- Firefox 99.0.1
- Bitwarden plugin 1.58.0
Is there any way to go back to a previous version of the bitwarden extension? This bug is a daily - hourly - every five minutes annoyance for me, just constantly having to remember to stop typing after i enter the first three letters, so that it can dutifully blank the entire field then restore the field - so that I don't type over that moment of blanking, and wind up entering 'gub' instead of 'github'.
Hi @ginat can we please get a status on this 5+ month old bugreport? It was an annoyance at first but has turned into a real daily PITA where I have a new muscle memory now when I go to use Bitwarden... click icon, type 1 letter, wait 2 seconds for BW to "think", and then type the rest of my search string. This is not how it should be.
Still affecting even the latest versions 2022.6.x
I don't really see any evidence that @ginat is either active or actually associated with bitwarden; I could be wrong. The only other contributor here appears to be @djsmith85, but other than closing other reports of this as duplicates, he doesn't appear to be interested in this bug either; again, I could be wrong.
Whats further frustrating is that before February 2022, this bug did not exist, so therefore it was introduced into the code on or about then. In my excruciatingly limited experience with coding, it shouldn't be much more than reviewing a diff to find what went wrong. However, I'll throw in my standard disclaimer again: I could be wrong.
It's still happening. I start typing, then it drops letters, then I backtrack to correct the dropped letters.
Hi @luckman212 @anastrophe , apologies for the inconvenience caused as well as the delay. This issue will be reproduced and will be given the attention it needs. We will definitely get back to you on this.
I looked through the git log for "search", didn't find much but this jumped out to me. I'm not familiar with the code base/logic to say if it's related, and there's a lot of different branches so not sure if/when it was introduced, but the commit date is January 20.
commit 025a4a5e3878bcc3f5126074f154e3d51aa9c091 Author: Addison Beck [email protected] Date: Thu Jan 20 16:25:04 2022 -0500
[bug] Index search service when setting decrypted ciphers (#620)
With the move to a central StateService we erroniously cut out search indexing from the process of setting decrypted ciphers to memory. This commit calls the method responsible for setting decrypted ciphers and indexing when decrypting, instead of setting decrypted ciphers directly.
@dbosompem Does it help or matter at all to note that this bug does not affect the "desktop" (Electron) app v2022.6.2? Only the browser extension.
I would like to add that this problem occurs on my system with these specs:
Bitwarden Firefox 2022.8.0 Windows 10 Firefox 103.0.2
Here are some concrete steps to reproduce:
- Begin with browser extension in the closed state.
- Open the browser extension.
- At a reduced speed, type out a long-ish search string. I used "testing" as my test case.
- When the first result set is rendered below the search box (while I'm still typing), the search string's value is reset momentarily to an empty string, and then restores to the state it was when the result set began rendering.
- Notice the missing letter(s) from the search text. For me the final value is "testng", indicating that my "i" keypress was lost.
Note that subsequent search are not affected while the browser extension is open. Only the first search after the browser extension is opened.
I took a quick peek at the code and suspect that, somewhere, the value of searchText is being mutated incorrectly. Maybe when it's normalized prior to filtering. Maybe elsewhere.
Hello everyone! I have been able to reproduce this consistently enough, and I can definitely understand the frustration it's causing. I'm going to turn our internal bug ticket over to the development team to find a fix so we can get this resolved.
Based on what I'm seeing, it looks like the issue occurs when the user is on the "Current Tab" view (the folder icon that says "Tab") and attempts to perform a search. Search logic doesn't kick in until the second character. Once that second character is entered the extension auto-switches to the "My Vault" view (the lock icon that says "Vault") and begins to load the vault contents. In doing so, the search component seems to reload, alongside the rest of the "My Vault" view, causing the first part of the search to disappear for a few moments and then re-appear once the "My Vault" view has finally loaded. It's during this loading event, triggered by switching from "Current Tab" to "Vault Tab", where any characters typed in the search component can possibly get lost.
TL;DR If you're on the "Current Tab" view, and attempt to perform a search, especially in a large vault, you can run into this issue.
The current workaround is to ensure that you are on the "My Vault" view when performing a search, as I have not been able to reproduce this issue when starting from there. That's not ideal, but hopefully this helps until a fix can be made.
@rdaugherty confirmed that workaround...works around the issue :-P Thanks for that suggestion and I look forward to a fix! :+1:
Yep Ive experienced this issue and it's just as @rdaugherty describes. If you start typing on the default 'Tab'... "Tab" letters might get dropped as it switches over to "Vault". Hopefully it gets fixed soon, as its extremely annoying.
Yes, hopefully some of that $100MM in funding they just landed is going towards developers. The pace of bugfixes in Bitwarden is frustratingly slow.
Not sure if you all mentioned it, but this happens to me in the browser extensions, but only on Chrome and Firefox.
When you open the browser extension, it defaults to "Tab" not "Vault" so that isn't really a "fix" in my mind, since there doesn't appear to be a way to change this.
On Safari it doesn't "stutter" like this and drop letters as I type.
Since Chrome is my main browser (I use Google Workspace) and Firefox is a backup, this happens constantly throughout the day to me.
Holy shit, $100 million?? Obviously it takes a few days for the ink to dry and the money to fill up the bank account, but - sure would like to know what plans there are for increasing dev staff. It's been seven months now since this bug was introduced into the code, and while I appreciate the statements back in July that this matter will be addressed, it does not seem that material bugs are a priority. The question is...what are the priorities? This is no longer the early days of an open source project funded by 'buy me a coffee' - this bug affects any customer using firefox or chrome. That's a LOT of affected customers.
Sorry for the harsh tone, but seven months to fix the damage of a one-liner diff....just no.
Hi all, we apologize for the delay in reviewing this and the inconveniences caused as a result. Issue has been prioritized and we are currently working on this issue , and would be resolved very soon. Thank you for your patience.
I now seem to getting the same issue, or at least a similar one, when entering my master password.
@drguildo Never seen that, but it's slightly terrifying. Imagine changing your master password and it randomly dropping the same keypress twice, poof you're locked out. 😐
Hi all, we apologize for the delay in reviewing this and the inconveniences caused as a result. Issue has been prioritized and we are currently working on this issue , and would be resolved very soon. Thank you for your patience.
Assignees: No one assigned Projects: None yet Milestone: No milestone Development: No branches or pull requests
I have a doubt.
@anastrophe, We don't use Github to track work. We've discussed how our decision to use outside ticketing software (Jira for now) will hurt transparency when we chose to use it. We have good reasons we wanted to use Jira (familiarity, broader feature set, discrete for security vulnerability issues), and those overruled for the time being.
We're always looking for ways to work better and more transparently where we can. Our solution for now is to tag issues we're working on in PRs we push up and open, as @dgoodman-bw did.
We also promise to not lie to you
