Bubble Search Input Bug (Gaslit by Support)

Has anyone else run into this?

Search inputs in my app literally don’t pull anything up when some words are typed, even when those words are the only thing typed.

For example, if you type “other” into a Bubble search input, nothing comes up, even if there are items in the list being searched that are named “other”. The same thing happens with “on”, “should”, or “yourselves”. Apparently, everything listed here doesn’t trigger the search.

This is what Bubble Support is telling me:

I’m at a loss as to how this could possibly be expected behavior. A search input that just doesn’t search some words?

It seems clear to me that this is an oversight in the design (a bug), but instead of fixing it, the engineering team is just wanting to sweep it under the rug by calling it “expected behavior”.

Any thoughts on this?

i do not think this is gaslighting.
i do think thats not a great decision by them. in specifically the word “other” is relevant to many organisations in searches
looks like you need another search (algolia, xano, your own bubble search index) etc

1 Like

Yup, those are stop words… known about it for ages and haven’t thought much of it. I just thought that’s how postgres search works… maybe something to do with efficiency or whatever, but I’m probably too dumb to understand it.

And I agree with Tass… they aren’t gaslighting… they are just giving you an answer. You are free to not like that answer (and to choose a different course of action as a result), of course, but nobody is gaslighting here.

1 Like

@TipLister @mikeloc

I see you perspective. I disagree. But I see it.

From my perspective: Bubble implemented changes to increase performance and minimize load. Changes of this kind often lead to bugs, which is fine, except when you tell users they aren’t bugs and are instead expected behaviors.

I’ve gone ahead and created a new entry on the ideaboard as support requested for anyone else who encounters this: https://bubble.io/ideaboard?idea=1698417994627x345866064073588740

I will be creating a search input from scratch using instant text and a focus group to work around this.

1 Like

I hear you, but the stop words were not introduced as part of any changes… it’s been like that forever, I believe. Alan even mentions stop words in this post from over 3 years ago.

Just because it is longstanding doesn’t make it not a bug. I don’t think that really has any bearing whatsoever. If something doesn’t work, it doesn’t work. The issue may even be with Postgres, not Bubble, but that doesn’t make it not a bug.

I acknowledge the fact that if next to nobody (apparently) is affected by the behavior, it’s not going to get changed and most won’t consider it a bug. I don’t understand how this is since this seems like a fundamentally blocking behavior to me, but I’m not going to waste any more breath on it.

Here is the list of stop words for future reference:


That is in my initial post, but thanks.

1 Like

A bug is something that is not intended. If it’s intentional than it’s not a bug. There is no arguing that.

Now if you want this intended behavior changed that would be a feature request.

So the question to ask now is if this is something bubble can change because it’s something they control or is this something built into postgres that bubble can’t change.

You’re right. I missed that link in your original post.

I’ve added it to the ideaboard already: https://bubble.io/ideaboard?idea=1698417994627x345866064073588740

1 Like