github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-13 05:34:14 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

Search performance, or perceived performance needs improved #805

New Issue
Closed
opened 2025-11-26 22:30:14 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-26 22:30:14 -06:00
Owner
Copy Link

Originally created by @DarkArc on GitHub (Aug 19, 2019).

I'm not sure why, but it at least feels like the old app searched faster. I've been searching for passwords on several occasions with "no results" only to get a result after I had mentally given up, and felt like that was the final answer.

I generally love the new app, but this has lead to me feeling noticeably confused. I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed.

One of my most common workflows on mobile is searching for and copying a password, so any improvements to search performance or perceived search performance would be much appreciated.

Worth noting, I don't have a particularly slow, or low end phone; it's the Pixel 2XL.

Originally created by @DarkArc on GitHub (Aug 19, 2019). I'm not sure why, but it at least _feels_ like the old app searched faster. I've been searching for passwords on several occasions with "no results" only to get a result after I had mentally given up, and felt like that was the final answer. I generally love the new app, but this has lead to me feeling noticeably confused. I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed. One of my most common workflows on mobile is searching for and copying a password, so any improvements to search performance or perceived search performance would be much appreciated. Worth noting, I don't have a particularly slow, or low end phone; it's the Pixel 2XL.
GiteaMirror added the bug label 2025-11-26 22:30:14 -06:00
GiteaMirror commented 2025-11-26 22:30:15 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Aug 20, 2019):

I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed.

I am not able to reproduce this issue. Search should already be case insensitive.

@kspearrin commented on GitHub (Aug 20, 2019): > I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed. I am not able to reproduce this issue. Search should already be case insensitive.
GiteaMirror commented 2025-11-26 22:30:15 -06:00
Author
Owner
Copy Link

@DarkArc commented on GitHub (Aug 20, 2019):

I am not able to reproduce this issue. Search should already be case insensitive.

Interesting, it's 100% reproducible for me, it requires a word to be typed either partially or completed for instance "hoover", then the suggestion "Hoover" to be selected. When the selection is made, the search reruns.

This is using Gboard as the keyboard.

Perhaps it's deleting the word, making the search an empty string, then almost immediately replacing it with the new title cased version of the word, making it a "change" from nothing to something, but not really from the user perspective?

@DarkArc commented on GitHub (Aug 20, 2019): > I am not able to reproduce this issue. Search should already be case insensitive. Interesting, it's 100% reproducible for me, it requires a word to be typed either partially or completed for instance "hoover", then the suggestion "Hoover" to be selected. When the selection is made, the search reruns. This is using Gboard as the keyboard. Perhaps it's deleting the word, making the search an empty string, then almost immediately replacing it with the new title cased version of the word, making it a "change" from nothing to something, but not really from the user perspective?
GiteaMirror commented 2025-11-26 22:30:15 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Aug 30, 2019):

@DarkArc I was able to reproduce this on my Nexus 5X with gboard. It seems that I am getting two search events whenever you tap the capitalized word suggestion. The first is an empty string, immediately followed by the new capitalized string. I don't know if this is a bug in the framework or what, but because the previous value (empty string) is not the same same as the new value, it fails that logic check to not search if the value is the same.

@kspearrin commented on GitHub (Aug 30, 2019): @DarkArc I was able to reproduce this on my Nexus 5X with gboard. It seems that I am getting two search events whenever you tap the capitalized word suggestion. The first is an empty string, immediately followed by the new capitalized string. I don't know if this is a bug in the framework or what, but because the previous value (empty string) is not the same same as the new value, it fails that logic check to not search if the value is the same.
GiteaMirror commented 2025-11-26 22:30:15 -06:00
Author
Owner
Copy Link

@DarkArc commented on GitHub (Aug 30, 2019):

Thanks Kyle, glad you were able to reproduce it. Perhaps a short debounce on searching could be used so that only the final result (i.e. the new word) is compared?

@DarkArc commented on GitHub (Aug 30, 2019): Thanks Kyle, glad you were able to reproduce it. Perhaps a short debounce on searching could be used so that only the final result (i.e. the new word) is compared?
GiteaMirror commented 2025-11-26 22:30:16 -06:00
Author
Owner
Copy Link

@DarkArc commented on GitHub (Sep 3, 2019):

This manifested in a weird way today. I've seen it before, but this time I was paying more attention.

If you have something stored like "Foo Bar", quickly type "foo", then press the search button on the keyboard, you can end up with "There are no items to list." even though there is indeed a valid item to list.

It's like the search button is somehow stopping it from going from that empty state to new value as far as the search system is concerned, or something. That said, the word "foo" remains in the search box. If you go back to the search box, and press search on the keyboard again, the results will appear.

@DarkArc commented on GitHub (Sep 3, 2019): This manifested in a weird way today. I've seen it before, but this time I was paying more attention. If you have something stored like "Foo Bar", quickly type "foo", then press the search button on the keyboard, you can end up with "There are no items to list." even though there is indeed a valid item to list. It's like the search button is somehow stopping it from going from that empty state to new value as far as the search system is concerned, or something. That said, the word "foo" remains in the search box. If you go back to the search box, and press search on the keyboard again, the results will appear.
GiteaMirror commented 2025-11-26 22:30:16 -06:00
Author
Owner
Copy Link

@alextmz commented on GitHub (Nov 10, 2019):

Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q.

My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective.

I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time...

@alextmz commented on GitHub (Nov 10, 2019): Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q. My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective. I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time...
GiteaMirror commented 2025-11-26 22:30:16 -06:00
Author
Owner
Copy Link

@AyoungDukie commented on GitHub (Aug 5, 2020):

This is also occurring for me on a Pixel (sailfish). Seems to be particularly sensitive during the first loading of data after a vault unlock, but rather snappy after. Is it potentially trying to fully refresh the vault on unlock? Would it make sense to allow for caching/incremental updates on this type of action, and leave full syncs to be done periodically in the background? I believe this is how I have seen competitor products work around allowing the user to relock the vaults frequently, which is obviously desired besides the performance hit.

@AyoungDukie commented on GitHub (Aug 5, 2020): This is also occurring for me on a Pixel (sailfish). Seems to be particularly sensitive during the first loading of data after a vault unlock, but rather snappy after. Is it potentially trying to fully refresh the vault on unlock? Would it make sense to allow for caching/incremental updates on this type of action, and leave full syncs to be done periodically in the background? I believe this is how I have seen competitor products work around allowing the user to relock the vaults frequently, which is obviously desired besides the performance hit.
GiteaMirror commented 2025-11-26 22:30:16 -06:00
Author
Owner
Copy Link

@3xploiton3 commented on GitHub (Sep 1, 2020):

Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q.

My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective.

I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time...

same happen on me, redmi note 5,
i already disable all other app, i think that's the problem, but issues come from bitwarden itself

@3xploiton3 commented on GitHub (Sep 1, 2020): > Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q. > > My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective. > > I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time... same happen on me, redmi note 5, i already disable all other app, i think that's the problem, but issues come from bitwarden itself
GiteaMirror commented 2025-11-26 22:30:18 -06:00
Author
Owner
Copy Link

@wjhrdy commented on GitHub (May 3, 2021):

I have this issue as well on my Pixel 5.

Right after the biometric auth, if I immediately click "search" and type away, results take around 7 secs (timed) to come up.

It also happens with autofill.

Seems like the sync process is blocking the search proceess.

@wjhrdy commented on GitHub (May 3, 2021): I have this issue as well on my Pixel 5. Right after the biometric auth, if I immediately click "search" and type away, results take around 7 secs (timed) to come up. It also happens with autofill. Seems like the sync process is blocking the search proceess.
GiteaMirror commented 2025-11-26 22:30:20 -06:00
Author
Owner
Copy Link

@clemlesne commented on GitHub (Sep 29, 2021):

Hello, I can confirm this issue, either on a Samsung Galaxy S20+ and on a Samsung S21 Ultra.

Searches are always slow, few seconds delay. From a user point-of-view, this is frustrating.

Any improvements to imagine with, perhaps, better indexing or another embedded DB?

@clemlesne commented on GitHub (Sep 29, 2021): Hello, I can confirm this issue, either on a Samsung Galaxy S20+ and on a Samsung S21 Ultra. Searches are always slow, few seconds delay. From a user point-of-view, this is frustrating. Any improvements to imagine with, perhaps, better indexing or another embedded DB?
GiteaMirror commented 2025-11-26 22:30:20 -06:00
Author
Owner
Copy Link

@AyoungDukie commented on GitHub (Sep 30, 2021):

I had been writing this off as a sync occurring, but I am not so sure now.

I actually encountered an odd occurrence recently where I was trying to log into an app on my phone (via autofill from Bitwarden), but using a login I had just recently created on my desktop browser.

  • Encountered the described slowness, but the new login was not found.
  • I then opened the app directly to scroll through the login list, and it wasn't there.
  • After checking the sync time, it turned out it was still from prior to me creating the login, i.e. the delay wasn't from syncing

Like I said, this was a very specific occurrence, but it does make me think there is something else going on.

@AyoungDukie commented on GitHub (Sep 30, 2021): I had been writing this off as a sync occurring, but I am not so sure now. I actually encountered an odd occurrence recently where I was trying to log into an app on my phone (via autofill from Bitwarden), but using a login I had just recently created on my desktop browser. - Encountered the described slowness, but the new login was not found. - I then opened the app directly to scroll through the login list, and it wasn't there. - After checking the sync time, it turned out it was still from prior to me creating the login, i.e. the delay **wasn't** from syncing Like I said, this was a very specific occurrence, but it does make me think there is something else going on.
GiteaMirror commented 2025-11-26 22:30:21 -06:00
Author
Owner
Copy Link

@AyoungDukie commented on GitHub (Feb 19, 2022):

Just to post an update, for me. On Version: 2.16.2 (4334), and one of the first few recent updates seems to have noticeably improved this. Thanks to the team!

@AyoungDukie commented on GitHub (Feb 19, 2022): Just to post an update, for me. On Version: 2.16.2 (4334), and one of the first few recent updates seems to have noticeably improved this. Thanks to the team!
GiteaMirror commented 2025-11-26 22:30:21 -06:00
Author
Owner
Copy Link

@vvolkgang commented on GitHub (Jun 20, 2024):

Issue migrated to https://github.com/bitwarden/mobile/issues/579

@vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/579
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#805
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?