So, I have a Button that set column values and then opens a link. That works fine.
Then, I have another button that calls a webhook, waits 3 seconds, and then, opens the same link as the first button. This one doesn’t work when I use the App on my iPhone. It works on the app builder and on the desktop web browser. But it wont work on the iPhone installed App nor the iPhone Web Browser.
The webhook is not related to the link the action should open.
Hey @Robert_Petitto you are always around! haha… Thanks for the fast answer man.
I’m going nuts with this. I had my beautiful app running beautifully. It is a stripe payment sequence (one time single payment using Stripe’s Payment Link).
But I didn’t like that the user had to close the window after the payment was complete. I wanted an automatic comeback to the last screen the user saw before pressing “PAY”.
I built a sequence using Make to create a specific payment link on the fly which has included the “link to this screen” inside as the “After completion” redirect url. It works great when the App is installed. Not so great on browser because you end with 2 windows with the same, but for now is ok. I could send the “old window” to a new screen with something…
The thing is that the “Open link” only works if is the first action or if it has a “Set column values” action before. If I place a webhook call and a “Wait”, it won’t open the link on the iPhone. (It does on the computer).
I’m changing the category of my post as a bug. And now adding a new button after the webhook call to open Stripe. It ruins the user experience, but for now i don’t have other option in mind…
It looks like a pop-up blocking thing. I was trying this on an old android smartphone and it showed a notification asking me to allow a pop-up window to open. If I press the button that opens the link instantly (or even with the “Set columns” before), it will open ok. But because it has these delay with the webhook and the “Wait” action, the browser “feels” it like a automated pop-up window. I think is not a Bug. It’s a behavior that depends on the browser.
I’m going to change my app to embrace this and go along with it.
I’m going to leave this post open just in case someone has work around, but I’m changing again the title and the category from “Bug” to “Help”.
It’s a bug. I raised it with Glide a few weeks ago. The problem is with Safari on iOS. If the pop-up blocker is enabled (by default), this action gets blocked and the user doesn’t have an option to “allow a pop-up”. In Chrome, you at least get a notification from the browser offering you a choice to allow the pop-up.
Glide has a tech team ticket for this bug but no ETA. I’ve followed up a couple of times, still no progress.
Perhaps, dropping a line to them might give this bug a bit more priority.
Thanks for submitting the ticket, I can confirm the behaviour. Not sure if they can get around it since it’s a browser problem, hopefully we hear good news soon.
Well, where I come from is…Glide must be an app builder for the real world today. And the real world today is the world of pop-up blockers, obsession with privacy, war on tracking, etc, etc. So the apps we build must be able to perform in this world. So, I’d say, it’s not a browser “problem” - it’s a defunct feature on the part of Glide. The action “open a link” must open the link for the user, not execute some code and then nothing happens that’s not what I’m paying for.
I did suggest to Glide that one of the ways around it could be to try and get the browser to open the link in the current window. They said thanks, and I haven’t heard anything since.
However, in my opinion, there are certain things that we, as Glide users and web-app builders, must embrace.
Regardless of how advanced these apps can become or how complex behaviors we can program into them, they still operate as websites running on web browsers.
Therefore, we are bound by the rules dictated by web browsers.
Recently, we were granted the ability to send notifications within iOS, something that should have been available to us for a long time. Having this feature is essential for any “app.” On the other hand, we can accomplish certain tasks in a timely manner and at a lower cost, which would be impossible for native apps.
I believe it’s quite challenging for the Glide team to support all actions and behaviors across different browsers and systems. We already find it difficult at times to create an app that looks great on various platforms and browsers. Thus, I can understand why certain things that seem simple to us can be complex to develop for the Glide team.
I have already found an elegant solution for the issue in my app without compromising the user experience. It involves an additional step in order to open the link, yes, but it feels natural and doesn’t disrupt the previous flow.
I’m currently running in this exact issue: trigger some actions to generate the payment link + open that link with the “Open link” action => blocked by iPhone!
Currently, the only way I see to overcome this issue is to use a dedicated coded web page for it. Stripe also support the “embedded form” option to do a checkout:
The way around it is to wait for the URL to be written into the row in your Glide table, and then serve the user a detail screen with the button linking to that URL. And a CTA that encourages the user to take action (eg “Pay”).
