Issue with autocomplete (search) with Geographic place

Bubble ask me to ask you… because they don’T know (want?) to fix this issue.
I see that the search Geographic place doesn’t work the same if you set your own Google Maps API keys in setting that without it. You can experience this here:
Search “Thon hotel”
in this page: http://skjema.fotobaren.no/version-test/test2
You will see some address in Vietnam and finally no results at the end.
Do the same search here:
https://buzzgame.bubbleapps.io/version-test/test
you will see differents (And expected) results.

After a long moment discussion with Bubble and Google, this appear that the call is not the same. One add the &libraries=places parameters but not the other one.

Actually, the only way I found to fix that is to… remove the keys. But I think it’s not a good solution. Any idea on other possibilities? (and that will work as fast as the search do)

Thanks!

  1. Open your browser console in the version where you’re using your own google maps api key.
  2. Check if google Google says you’ve exceeded the limit
  3. If it does, its possibly a problem with your payment method. Go to the billing account section on google developer console and fix that.

Google changed its policies. Even if you have free google credits, you still need to have a valid billing account for the keys to actually work fully.

1 Like

No this is not an issue. Billing is correctly enabled on the account for keys (and not error in console).
And I don’t think this will change the request made by bubble anyway (with or without the &libraries=places param. If I have time, I will try to create my own call outside of bubble and see with the same keys.

Have you enabled the Google Places API on your own Google API Console?

(That is to say: is your key authorized for Google Places? Because that would explain the difference in how a search with bubble’s Key behaves and how your key behaves.)

Yes. No issue on auth for keys and use. I can also confirm that all requests appear in my console in Google.
And by the way, I forget to tell that I’ve also try with the Bubble key itself… same result. If I set it in my settings API keys, No results for Thon hotel.
I will no provide the bubble key, but if you have an app whitout keys set, you may be able to find it in browser console. Just copy and paste it in the setting and you will face the same issue.

Welp, I see the two projects create different results, but it’s not clear to me that the projects are otherwise identical, right?

But these projects are not “identical”. There are some differences that (who knows?) could be important:

  1. There are definitely different calls showing up in the Network tab on the one versus the other. (Are these two searchbox elements really the same thing? Are both projects on the same version of Bubble?)

  2. The one app is on HTTPS, but the other doesn’t connect on HTTPS at all.

  3. One of the apps has a test-mode plugin installed while the other one doesn’t. Hmm.

So, these projects ARE NOT identical.

Anyway, any further help that you could get from the Forum community would involve sharing edit mode. Here’s what I’d do:

  1. Make a copy (or two) of your buzzgame project (this is the one using the Bubble key, right?). Leave one just as it is now.
  2. In one of copies, change it to use your own key (go ahead and make a NEW key for this purpose - configure it the same as your existing Google key with access to all the same stuff).
  3. Don’t change anything else between them.

Do the two projects really behave differently?

If so, share those editors here and somebody might take a crack at solving this mystery.

Thanks for taking time. The buzzgame project is not the one with keys.

Here’s two identical app except for key (created new one and copied it)
https://gmapissuenokey.bubbleapps.io/version-test
https://gmapissuewithkey.bubbleapps.io/version-test

Editor:


I have created new keys for that and checked to be sure that everything was fine.
I also created this page:
https://gmapissuewithkey.bubbleapps.io/version-test/test2
That is a different implementation of a google script autocomplete but with the same key. Results are near the without keys and this call is using the parameters librairies=places that is not used with keys.

Thanks again!

The gmapissuewithkey project did not open for me (https://bubble.io/page?id=gmapissuewithkey is the link – is that not set to everyone can edit, perhaps?)

Sorry. This is updated now

Why are there two searchboxes on each page?

I don’t know. Deleted. But this is open for edit, so maybe someone else add it

Should I set it to view only?

No. I’m just curious. Are you sure YOU didn’t put them both there?

Anyway, in one of them you deleted the wrong one.

ALSO. Since these are both Hobby (free) projects, how did you manage to make their API keys different? There’s no place to enter that. Where does that happen???

Maybe I’m lost. I set it in Settings / General tab

No, you didn’t. Because you couldn’t have.

And this is one of my points about this exercise: If you REALLY want to suss out if one of these things is different, this is what you have to do. Make a really simple de-minimus example like we just did.

Also, you will have to momentarily at least put one of these things on Personal so you can enter your own custom API key. I’m not suggesting you do that now, as I’m not looking at this further, myself.

Make no mistake the “no key” project HAS A KEY. It’s just that it’s using Bubble’s default key.

If you take your “haskey” version (the one you’re going to put your own key in) and put it on Personal, and you enter your key and the behavior is DIFFERENT. Well, you will know the cause: Because something is different about YOUR key and API Dashboard settings than Bubble’s key and associated dashboard settings.

And then you can futz around with YOUR Google API dashboard and try to get the results to act the same. Who knows what the issue might be? I don’t.

But I’ll tell you this: If you do what I describe above THE ONLY POSSIBLE difference would be how you’ve got your key and console configured.

See?

Just to clarify: If you do this and find the results different AND you have Places API enabled, the problem is very clearly on Bubble’s side and they could definitely act on that info.

… and as I write this I see that @dan1 has perhaps discovered this same issue, perhaps.

(I ran across a similar thing with Bubble’s implementation of Google Timezone API. For a time, they were not signing their calls with the custom key. Could be a similar thing going on here. But I had to make a very minimal example that clearly showed that this was the case. Not in my actual app, but in a brand new project where it was obvious that there are no other issues.)

Maybe you don’t have access to this part of the app because I can set it without any issue. Two screenshot
http://nimb.ws/q4yfkM
http://nimb.ws/LDR63b

I got the same issue with support actually where they say they cannot do anything and think that both call are the same but I’m pretty sure it’s not. I will reply with the two new app so maybe they will understand a little bit more.

Thanks for your help and time!

Ah, I see… Yeah, must be hidden unless you’re actually ON the account, even if it’s a freebie. OK, sorry 'bout the confusion there.

Well, yes it looks like – from this nice and narrow example – that indeed search results are not being returned when you enter your own key. I know it’s a pain, but just open / re-open your bug report on this with links to these demo apps. Include a screenshot of your Google API dashboard to prove you’ve got Places enabled!

It’s pretty clear that something’s definitely wrong with Bubble’s implementation when key is customized. Sorry I can’t be of more help.

At least it seems other folks have noticed this problem too. But note that it’s best to file a formal bug report as that’s how the Bubble team tracks time spent on features. It’s much more likely to get fixed if you file a new bug report via the online form!

1 Like

Thanks!

@Jici It looks like we might have missed a lot of context in your initial bug report. We will take another look.

1 Like