Forum Academy Marketplace Showcase Pricing Features

Using 'Back' in a browser loads old data - Normal or bug?

I have a page that is set to a certain data type, where on page load workflows run and certain fields get reset if the piece of Data meets certain requirements (example order is UNPAID).

The data gets changed when leaving the page (example, mark the order as PAID), and if the user on the new page clicks Back in their browser they are redirected to the Order page, and the Order (now PAID) is loaded as it’s old Data values (as UNPAID)

This runs the conditional workflow above I described and edits a Paid order in ways I do not want. Should it be doing this - loading old Data values on ‘Back’, and if so any ideas for workarounds to avoid unintended editing of Data?

An example of this Loading Old Data can be seen using the quick example I whipped up in the forum app.

That seems like normal behavior to me since you passing the data as a parameter. If you don’t want that why don’t you save that data to the current user on an appropriate table and update and check the value from the database instead?

Hmm, thanks for the info, might need to use the Current User technique then. From a non-developer standpoint I did not expect this functionality.

So if this is normal, then I am guessing I should only use a Page Data Type for a piece of data that CANNOT get edited on that page?

Because… Edits that get done --> navigate to new page --> Back to old page… all the old data will be showing and workflows will be run off of the old (and no longer true) data values.

My thinking was that when the workflows get run on that Parameter (such as an On Page Load), that it would load/view the piece of Data and it’s current values. So by putting data on a Page it is actually showing a piece of Data from a specific point in time (when it gets sent), not its current value?

I’m not sure as it relates to the browser session I think…

The sure way I would recommend you do it is to use the database tied to the current user who is logged in. So for each step you when they hit submit you update and check the current user paid/unpaid field. That way you can access it and know the current value in the future. This way if they navigate back to the old page you can verify that oh they already paid so you can actually disable the submit button for already paid accounts.

1 Like

Thanks for the discussion, there is a little more complexity on the page than a Buy button, so I came up with another workaround that isn’t perfect but will stop the current ‘Bug’ Users had.

I did try using a page that uses Current User information and a similar problem was happening (although might not be exact same, can definitely lead to ‘Bugs’ from Users who use the back button).

I have an Account page where the user can update their Name and info. On this page I updated my Current User’s Name no problem, navigated to a different page, then used the Back button.
The input that is set to ‘Current User’s Name’ was showing the OLD name I had put in for myself (I am the Current User)

Had to refresh the page for it to show correctly. This makes me think that using ‘Current User’s’ instead of the Page data type might not help, as it is still referencing My Current User from an earlier point in time
I feel many more Bugs coming my way if my Users keep using the Back button…

Ah - found a thread on this…

There appears to be no workaround for this beyond hitting refresh on the browser.

This is normal browser behavior to me as when I hit back I expect to see what I had before - not what changed.

One more interesting thing is that on this forum if you like something then go to another page then go back it shows the “updated” item. So now I’m thinking it’s not expected behavior since the forum is run on a different software platform and must be bubble specific behavior.

Ya, I always thought that even when going Back, that data would show it’s values from the moment I left it (changes before I leave the page, this is visible in the forum example I put in). For most websites this seems true, but on Bubble it seems to revert and use the data from it’s earlier point in time.

Does Bubble load (or not load) data in a specific way that leads to the data showing incorrectly (from a previous time) when using the Back button in a browser?

Yes, for performance purposes, the page thing is added in the raw HTML so if you go back you’ll get an older version, and it will be updated after a while.

Not much we can do about this, most sites (facebook, etc.) will have similar behavior when you click ‘back’


I think it’s a good compromise then as I would choose performance over having the back functionality. I would just refresh the page if I thought something looked odd.

I would also address the issue on the page I made if it had an impact to me. There are many sites that say don’t push the buy button multiple times as it will result in multiple buys. Also many sites say don’t use the back buttons specifically.

So I would also think of approaching it that way.

1 Like

Thanks @emmanuel, this is good to know and I will try adjusting how workflows and conditionals are used so that Users won’t change or access data they shouldn’t be

Actually just double checked. And this seems to use Data from the Current User that is old as well - so not just the Page Thing.

So I am guessing Current User Data is added in the raw HTML too? @emmanuel

As I tried moving the conditionals to the Current User like @john3 suggested, and when I hit back it checks Current User data from a previous point in time and not the current values of the Data.
Confirmed they were different values by comparing Debugger values to the Database values

So I currently do not know of any single way that I can hide/show/adjust workflows on a page if a User goes ‘Back’ to it. As all data on the ‘Previous Page’, even Current User, appears to be from a point in time before they first visited that page. Any ideas out there?

Yes, it also applies to the user

Did you find a solution to your problem? I’m facing the exact same use. Having to explain to users that they need to Refresh is not really a solution.

I found a solution myself. I put an action on page load that updates the Parent’s Thing. I just update the value to the current value.

It’s not pretty but it solve this problem of going back. But it means an extra trip to the database whenever the page loads, but I prefer that over the users’ confusion about the Back behavior

1 Like

I had adjusted the way the data was manipulated on the page which helped the original issue but it did not solve the old data being loaded.

Despite adding an extra step on the page load, it sounds like you found a great solution, thanks for sharing!