How to prevent browser message "Leaving site? Changes you made may not be saved."?

[sridharan.s]

There are numerous places within our app where users sometimes get an error message like the one below even when they didn’t fill out a form or submit any data, and seemingly no particular workflow being run, etc.

It makes people think our site is broken - and, in my opinion, when users see something like this and they’re not submitting information then it is broken. It’s horrible UX and makes us look bad.

I can’t figure out what’s causing this in Bubble. It happens to me semi-frequently and I can’t identify any particular pattern of actions that’s causing it. And, I’ve seen our users hit it on several different pages so it’s not just 1 workflow that’s got a bug or something.

Does anyone have an idea how to prevent this message from being displayed?

[JohnMark]

It sound’s to be a particular plugin and not a Bubble main error message.

[mishav]

Were you able to match up the time of an occurrence with the server logs? Although going through the logs is kinda tedious.

[sridharan.s]

Yeah, I’ve reviewed the logs and didn’t see anything that seemed off. No errors, no failed workflows, etc.

Hard to know if there was a workflow running at that time since there’s only a single timestamp per workflow and not a workflow started time and workflow ended time.

[JohnMark]

I feel it’s a javascript conflict. Maybe run as without any plugins and see if you still have the error.

[mishav]

Does the message match one of the messages in Settings > Languages?

@JohnMark

It sound’s to be a particular plugin

Bubble’s chart plugin has a listener for beforeUnload.

[fayewatson]

@sridharan.s I sometimes get that browser message when a few custom state or element actions haven’t finished in a custom event workflow (on a page without any plugins)

[sridharan.s]

Thanks for the help.

@JohnMark - it looks like it may be coming from a 3rd party widget called Crisp - it includes “beforeUnload” in numerous places so it’s the prime suspect. I’ve reached out to them for clarity.

@mishav - It doesn’t match a message in Settings > Languages. We have a lot of plugins but not Bubble’s chart plugin. I am seeing “beforeUnload” in two additional files on our site. Any idea how to best evaluate whether they’re the culprit given that I can’t quite read the code well enough to myself?

@fayewatson - good to know! Thanks. This is also a prime suspect for us since it happens much more frequently on our most complex pages which have lots of custom states and complex workflows.

Does anyone know a way to simply override/nullify this behavior. While I’d prefer to stop it at the source, it sounds like there may be multiple potential causes, some of which are beyond my core skill set, and I’d hate to spend many hours on this if there were a short-cut.

[keith]

I gotta ask… your app is obviously very sophisticated… WHY do you have any plugins installed beyond @mishav’s Toolbox and native Bubble stuff? Know whut i’m sayin’?

It’s just asking for trouble, is it not?

[sridharan.s]

The simple answer is there are capabilities that we need/want that aren’t native to Bubble. Some of these capabilities are pretty much required and while we could solve for most of them without a plugin, those other solutions would have their own problems.

We haven’t had much trouble with plugins. Once we can get one working cleanly, we haven’t run into regression issues.

[sridharan.s]

After some additional exploring, it’s not exclusively Crisp for sure since I’ve found instances of it happening on pages that don’t have any code from Crisp.

I’m also finding it frequently on a page that only has “beforeUnload” in 2 other places on the page - both from the same file, and both seem to be from our Bubble app.

Does anyone know what the following code implies might be the root problem?

Code Screenshots

Here’s the file:

Here’s the code:

[mishav]

@sridharan.s

Does anyone know what the following code implies might be the root problem?

Minified code is unpleasant to interpret, plus its hard for you to know how much context to give.

Some options I see are:

Working out a sequence of steps to reliably reproduce the message - you may need to try things like having the browser simulate a slow network speed.

Getting the Bubble team to investigate what looks like their code base, and have them tell us what conditions cause this message, and what we and they can do about it.

[JohnMark]

It can be infected machines with some kind of new spyware that tried to disconnect (ping…) You have long hours in front of you. You need some kind of sniffer to catch all network traffics, worst case scenario. Maybe you can duplicate the app, remove everything essential, so we can test on different system to replicate the problem? Be happy to find that buggy

[sridharan.s]

Okay, so I think I found one culprit (and perhaps it’s the same flavor problem everywhere). And, there’s a small lesson to learn from this…

We have a reusable element that’s a popup, and is included on multiple pages. I had included an “x” in the top right corner to close the popup, and when clicked it’d animate the box to slide up. Additionally, I had a separate action to animate the box to slide up when the user closes the box (i.e., when they click outside the popup to close it). Well, it turns out that when you close it with the “x” Bubble’s debugger shows only 1 of those workflows running, but it seems as if there’s a conflict and it takes a long time to decide to slide the box up (e.g., 10 seconds) and a workflow continues to run in the background (perhaps, in perpetuity). So, when the user would navigate to another page, they’d get the error message because an action was, in fact, still running (even though it’s not shown in the debugger).

So, the lesson learned is don’t add animations to popups when the user closes it by clicking outside the popup. Secondary lessons may include: when things don’t work as expected try deleting elements or workflows to see if they’re the culprit, and sometimes the debugger has bugs too so don’t be too trusting of its results.

[mishav]

I also get this message for:

Disconnect the network connection
Workflow step that updates the database
Close the browser

Does your workflow for closing the popup do any database or server interaction? If not, there is no need for the prompt, so you can raise a bug on it : )

[keith]

I actually think this is a bug/inconsistent behavior/unanticipated use case. I find that I can trigger the “Leave Site” dialog by attempting to load a new URL in my app’s parent window.

For example: parent.window.location.replace("someURL");

(Other similar techniques for URL loading cause the same behavior. The issue seems to be triggered by accessing the parent container.)

This does not happen if one uses “Open an External Website” (which targets the app’s window – not the parent above it).

The reason that I need to redirect the app’s parent window, by the way, is that my app creates embeddable widgets which can be hosted in iFrames. What I’m trying to do is add support for custom redirects in response to certain actions in my app.

For example, in my Booking Widget, some of my users want to be able to redirect the browser after a visitor has submitted a booking inquiry. This would be useful for loading either (a) a customized “thank you” page and/or (b) a page that includes a tracking pixel or tag, etc. so that they can track conversions.

What I find is that at present, one is only able to load a new page inside the iFrame hosting the widget without triggering the “Leave Site” dialog.

I’m looking for workarounds, but I’m going to be describing this behavior in a new post and also submitting a bug report / request for enhancement. It looks to me like one does need some sort of mechanism for forcing the Leave Site dialog to NOT appear and/or intercept it.

This behavior happens whether the current user is logged in or not, BTW.

It also happens even if you disconnect the redirect behavior from any other workflow actions. For example, at the end of the “submit inquiry” workflow, I tried setting a Boolean custom state (“Do Redirect”) to yes. And then I have a “Do when condition is true” that just listens for that state being yes and, in response, triggering a Custom Event workflow that handles the redirect.

@sridharan.s it might be helpful if you also submitted a bug report about this behavior. While it may not be a bug, there are some very valid use cases for being able to defeat the “Leave Site” dialog!

Regards,
Keith

[keith]

My bug report has been submitted as Bug report #4438.

[JohnMark]

edit: just catch what you mean in your other post…
Good point, Bubble must give a choice to remove the banner. But can you catch that error message in ‘on error’ thing? probably not…

[keith]

Wasn’t aware of that plugin, but that’s not helpful in this particular case. What I’m doing is intentionally redirecting the browser/container. The issue is that Bubble will not let that happen silently in some cases.

(That feature is very useful in many contexts. However, in my particular context, the “user” is not at risk of losing any data and I really really mean to direct their browser to a location outside of my app. Further, I need this to happen programmatically, without the user having to click.

I’ll note that, if it were OK to do this on some sort of separate user click, I could just use a link element for that and I wouldn’t have any problem. The point is that the user has clicked a button which submits some data and some workflow stuff happens. Once that workflow is complete, we desire to redirect them to another page, which may or may not be on another domain, and have that happen silently.

BTW2, the “Leave Site?” dialog will, in fact, be triggered even if the redirect URL is on my own domain/a page in my app. It basically seems to be triggered by attempting to redirect the parent container, regardless of the destination in question.)

Saw your edit, but figured I’d post this clarification anyway! Appreciate your participation!

[keith]

As for error catch (which is a good idea), there’s no error to detect when this happens, as shown by this image with the console visible:

All of the logging there at right are messages coming from my own app, there are no Bubble error conditions being thrown.

I’m currently looking at whether one might defeat this modal popup using some clever css or something. (Would be far better just to have access to this feature from one’s app though!)