Recent Notes Doesn't show up in Search [Brave Extension]

[Laro]

So, when I add a new Note (I keep all info about my Sound libraries in Bitwarden) with a header similar to an existing Note, it typically doesn’t show up when I search for it in my Brave Extension. Example:

1- “The Orchestra Complete 3” (existing)
2. “The Orchestra Complete 4” (new)

The only way I can get hold of the new version (4) is by logging in and search in the Web Vault. The Brave extension simply refuses to show the new entry, no matter the search combinations I try.

This seems to be a generic problem for items starting with the same header string/characters. The programming logic obviously skips all hits except for the first match.

This has been going on for quite a while, at least the last one or two years.

Can someone else try it and confirm they see the same phenomenon?

//Laro

[grb]

@Laro Welcome to the forum!

@Laro

Can someone else try it

Please specify a search expression that works in the Web Vault, but that does not work in the Brave extension. I don’t have Brave, but I can test it in Chrome.

@Laro

This seems to be a generic problem

If I had to guess, the “generic problem” is that the search engine used in Bitwarden (Lunr) can only search for “tokens” (e.g., words), not for phrases (because tokens are any contiguous strings of text separated by whitespace and/or hyphen characters -).

You will likely have better luck with searching if you reduce the use of spaces in your vault item names — for example:

The_Orchestra_Complete_3
The_Orchestra_Complete_4

Alternatively, don’t rely on searches finding tokens that consist of a single character (e.g., 4) — for example, you could name your entries as follows:

The Orchestra Complete Vol3
The Orchestra Complete Vol4

[Laro]

@grb

Please specify a search expression that works in the Web Vault

Any part of the header string is found as a match in the Web Vault. Example:

At no point does any search expression, whether partial or literal, find the last entry in the header in the Brave Extension (in this case the last entry is; “The Orchestra Complete 4 - Sonuscore (upgrade)”)

@grb

If I had to guess, the “generic problem” is that the search engine used in Bitwarden (Lunr) can only search for “tokens” (e.g., words), not for phrases (because tokens are any contiguous strings of text separated by whitespace and/or hyphen characters -).

This does not appear to be the case. As I pointed out earlier, the Brave Extension does find all instances containing any word, part of a word, or the entire header string — except the last one registered in the Vault.

@grb

You will likely have better luck with searching if you reduce the use of spaces in your vault item names — for example:

The_Orchestra_Complete_3
The_Orchestra_Complete_4

I tried also that, but no go. No difference to the results I describe above.

@grb

Alternatively, don’t rely on searches finding tokens that consist of a single character (e.g., 4) — for example, you could name your entries as follows:

The Orchestra Complete Vol3
The Orchestra Complete Vol4

Same here; No go. The last entry in the vault will not show up in the Brave Extension.

In short, this is now a fairly well-defined bug. The last entry is not included in the search match algorithm for some reason.

//Laro

[grb]

What you’re experiencing seems similar to what was described in Issue #15880 on Github. However, that issue was closed by Bitwarden staff, because the information provided by the submitter was not sufficient to reproduce the issue.

I would suggest that you try to complete the test that was suggested in this Github comment. Please report back to let us know whether the issue does or does not occur when you follow the instructions from that test example.

If we can find a way for other users to reproduce the issue, then it should be possible to open a new bug report on Github.

[Laro]

There’s a difference between my case and the Issue #15880 on Github.

My case is a Note, not a Login.

If UI were a developer I would look out for a code looking something like this (I illustrate with C#, but any language have an equivalent):

for (int i = 0; i< ListOfMatches-1; i++)
    // print list to UI

The code above stops traversing the list at next to the last item in the list (because there’s a double constraint, the “<” and the “-1”)

Removing the last “-1” will allow the loop to reach the last item in the list, like so:

for (int i = 0; i< ListOfMatches; i++)
    // print list to UI

Now this is of course only my guesstimation, but I’ve seen this kind of bugs a number of time in my long but useless life.

CORRECTION:
I just tried to add a new “dummy” to the list, and that proved my theory above to be wrong. I added the following entry,

The Orchestra Complete - DUMMY!

but that did not enable the previous (next to the last) entry to show up, so it’s not a list-loop error on the final result list, it’s has to be an error closer to the matching algorithm itself, which skips recent entries to the Vault. Some flag or filter isn’t updated it seems.

But I’ll try also the Login test, although not directly related. I’ll be back.

//Laro

[Laro]

OK, so I tried entering three Items according to the test. like so:

However, when a search string is typed in (I tried “Item”, “Item1” etc), none of the registered items showed up. Nada.

Conclusion: The search algorithm is obviously totally broken.

This test was performed using the latest version of Brave (Brave 1.81.131 Official Build, 64-bit) on a Windows 10 computer with the the following Bitwarden extension version installed.

Version: 2025.7.0
SDK: 'main (f2bc708)'
Server version: 2025.7.3

//Laro

[grb]

@Laro

However, when a search string is typed in (I tried “Item”, “Item1” etc), none of the registered items showed up.

Would you mind posting a screenshot showing the search expression and the search results?

Also, in your screenshot, when you have no search term, there are only three “ItemX_Issue15880” items shown. The bug report on Github suggests that you need at least 6 similar items in your vault for the bug to manifest. Did you follow the instructions to clone the item 5 or more times?

Furthermore, I don’t think it matters whether the item type is Login or Note. Here it is working correctly for Notes (in Chrome extension 2025.7.0):

 

Have you tried this in any browsers other than Brave?

[Laro]

I can add another three items, but as indicated, the bug appears already after three. I’ll be right back.

[grb]

@Laro

the bug appears already after three.

Do show the requested screenshot, if possible.

[Laro]

I didn’t take a screenshot of the failed search (“Item”) when I had only three items.

For other reasons I had to restart my computer, and after that the serach worked fine, and I added another four items, 7 in total, and the search seems to find all items, including the Notes that I had problem with in the original post.

It seems the (Brave) browser needs to restart to trigger the Bitwarden extension to update properly.

The search result after restarting the Computer&Browser:

I’ll try to register a n ew set of items with different names, since the restart wasn’t supposed to be “part of the test” so to speak.

Anyway, this indicates a cache not being updated properly while in the same session.

//Laro

====================================
NUMBER OF FORUM POST LIMIT REACHED

Can’t reply to your last post below, so I can only edit (add to) my last post like this. Consider this being my reply to topic:87711:

@grb

Please let us know when you have found a set of conditions & steps that consistently reproduce the issue, and can be tested by others.

To me it is obvious what precedes the bug: Brave Browser being up running for a longer period of time (meaning days, which is the case for me).

The bug “last entered item doesn’t show” has happened CONSISTENTLY to me over the last two years (but I notice it only when updating a software version with the same name).

The only new thing I learned today was that if I restart the browser it goes back to normal and search works as expected again. Some cache overload or something.

Long time build up of a cache isn’t reproducible unless you let the computer do just that - leave it running for days before entering another item with the same name. As said, it happens consistently for me. That’s all I can help with. A newly opened browser session does NOT have the problem.

All this taken together is very specific bug description, enough to put the developers on track. I’ve done debugging for years full time. Cache bug. Overflow of some kind, built up over time. That’s all. Doesn’t happen in a fresh session excludes any specific entry pattern to reproduce the bug.

(I of course have tried also to “sync” the vault, no go (on an old session that is)).

That’s all.

[grb]

Thank you.

Please let us know when you have found a set of conditions & steps that consistently reproduce the issue, and can be tested by others.

Also, if you are creating new items in one client app (e.g., the Web Vault) and then having trouble searching for those items in a different client app (e.g., a browser extension), it is likely that a sync issue is the problem. You should be able to fix such issues by doing a manual sync (e.g., in the browser extension, go to Settings > Vault Options and click “Sync Vault Now”).

[grb]

@Laro I just saw the following response from you, which you had inserted as an edit into your comment above:

@Laro

NUMBER OF FORUM POST LIMIT REACHED

Can’t reply to your last post below, so I can only edit (add to) my last post like this. Consider this being my reply to topic:87711:

@grb

Please let us know when you have found a set of conditions & steps that consistently reproduce the issue, and can be tested by others.

To me it is obvious what precedes the bug: Brave Browser being up running for a longer period of time (meaning days, which is the case for me).

The bug “last entered item doesn’t show” has happened CONSISTENTLY to me over the last two years (but I notice it only when updating a software version with the same name).

The only new thing I learned today was that if I restart the browser it goes back to normal and search works as expected again. Some cache overload or something.

Long time build up of a cache isn’t reproducible unless you let the computer do just that - leave it running for days before entering another item with the same name. As said, it happens consistently for me. That’s all I can help with. A newly opened browser session does NOT have the problem.

All this taken together is very specific bug description, enough to put the developers on track. I’ve done debugging for years full time. Cache bug. Overflow of some kind, built up over time. That’s all. Doesn’t happen in a fresh session excludes any specific entry pattern to reproduce the bug.

(I of course have tried also to “sync” the vault, no go (on an old session that is)).

That’s all.

 

First, to avoid strict post limits in the forum, it is necessary for your Discourse forum “trust level” to be promoted from “New User” to “Basic User”. This happens automatically after you spend some time (<30 min, in my experience) participating in the forum by reading posts in various topics of interest to you.

Second, thank you for the additional information.

@Laro

happened CONSISTENTLY to me over the last two years

Just to make sure, is what you wrote above correct — your assertion is that the Bitwarden browser extension has had this bug for two years?

@Laro

Long time build up of a cache isn’t reproducible unless you let the computer do just that - leave it running for days before entering another item with the same name.

Could you please expand on the process you are describing above? To reproduce the issue, one should open the browser, create a vault item, then wait several days before creating a second vault item with a similar name, at which point searching for the second item should fail? Is this correct? During the waiting period, must the browser be actively used, and does the browser extension need to be actively used? If so, can you estimate some minimum level of activity needed to cause a cache overload (if your hypothesis is correct)?

For the record, I routinely leave my browser (Chrome) open and running for many days at a time, during which I frequently use both the browser and the Bitwarden browser extension. Despite this, I have not been able to reproduce this problem, even though I have attempted it several times.

[Laro]

@grb

Just to make sure, is what you wrote above correct — your assertion is that the Bitwarden browser extension has had this bug for two years?

Yes.

Or, “as long as I can remember”. Could be more than two years.

@grb

Could you please expand on the process you are describing above? To reproduce the issue, one should open the browser, create a vault item, then wait several days before creating a second vault item with a similar name, at which point searching for the second item should fail? Is this correct?

Correct, except for it doesn’t have to be that I create a vault item in the beginning of the session. What I experience (and it follow from the example) is that and existing vault item with the same (beginning of the string) typically was registered a year or so before registering a new one. (Updating software and sound libraries etc, so updates typically happens once a year or so).

My normal hours using the computer spans from 8 to 36 hours straight (…) including quite extensive browsing (100+ tabs in groups), get some hours of sleep (yes, sometimes I have to finalize some programming instead of losing the whole thing by falling asleep…) while the computer stays up running, including the browser running in one monitor (I have a four monitor setup).

Right now, a few days after last post and after restarting the computer a number of times, the search results still doesn’t find exact matches although it does find the item searched for somewhere down the result list.

Totally arbitrary nonsense result (apparently listing matches for each word in the search field to begin with, instead of prioritizing a whole string.match). Which I think is total nonsense. That’s not how a search function should work.

But of course, even worse is of course to not get a match at all directly after registering a new vault item with the same or similar name (from the start of the string), as described earlier.

@grb

For the record, I routinely leave my browser (Chrome) open and running for many days at a time, during which I frequently use both the browser and the Bitwarden browser extension.

Yep, that’s the same for me.

I use Bitwarden Notes a lot, for everything like software license numbers, car info, car parts etc, etc, + several hundred login accounts (having many areas of interests including software development, music production, 3D CAD, aso)

What differs seems to be that I use Brave instead of Chrome.

//Laro

[grb]

@Laro

Right now, a few days after last post and after restarting the computer a number of times, the search results still doesn’t find exact matches although it does find the item searched for somewhere down the result list.

The above sounds like the normal operation of Bitwarden’s Lunr search engine, and if the item searched for does appear somewhere in the search results list, then this is not related to the bug being discussed in this thread.

@Laro

That’s not how a search function should work.

There are relevant Feature Request topics here and here, where you can vote and/or add your comments.

@Laro

But of course, even worse is of course to not get a match at all directly after registering a new vault item with the same or similar name (from the start of the string), as described earlier.

Let’s focus on this, so that there will be a chance to come up with a set of criteria that will allow others to reproduce the bug. Two relevant bug reports have been posted on Github (#13120 and #15880), but both reports have been closed by Bitwarden staff because they were unable to reproduce the issue. Thus, the bug is unlikely to get fixed unless we can make some progress in identifying conditions that consistently reproduce the buggy behavior.

[Laro]

@grb

The above sounds like the normal operation of Bitwarden’s Lunr search engine, and if the item searched for does appear somewhere in the search results list,

Even this issue is relevant because:

1. If you search directly after registering a new item, as described earlier, the item does not show up at all.

2. After restarting the browser and computer, the desired DIRECT MATCH appears far down the list instead of at the top. For a direct match!

   This in itself indicates that the search algorithm is amateurish and should be replaced with the simplest possible Regex match. Keeping this algorithm will prevent you from solving several real-world problems down the road. Throw it in the bin. I’ve never seen a more nonsensical search than this. I’m serious.

After dabbling with software development for over 35 years, if there’s a real problem with the algorithm that’s difficult to reproduce, I would start reading the algorithm and any dependencies. Yes, I mean reading the actual source code.

If not seriously interested in solving real problems — and there are several ridiculous problems with this algorithm, as I have pointed out — then don’t read the code. If it’s too messy to read and understand, well, then scrap it and replace it with a simple Regex. Problem solved.

//Laro