Skip to Content (Press Enter)
2020-08-05 08-52-58
Ruben Goncalves
3436Views
11Comments
How to: disable back button?
Question
Hi guys,
Has anyone been requested to block the browser back to button?
I’m trying to "disable"/inutilize the browser back button, so that the user may not go back. I’ve tried the following approaches:

·         window.history.forward() - Result: it the same as clicking in the next button of the browser. So if you click back, the previous page will load, the preparation will run (not even IsLoadingScreen() avoids) and then move forward to the page were you were before hitting back. No good!
·         Change the URL on load: Terrible, this is a new request to the url, besides click twice in the back button and you’re already on the previous page, No good!
·         Have a proxy page between pages (the proxy page would redirect to the correct page): doesn’t work, the browser redirects to the previous loaded page, No good!
·         Add the metatags to (try) avoid the browser to cache the pages: No good!
                o   <meta http-equiv="Expires" CONTENT="0">
                o   <meta http-equiv="Cache-Control" CONTENT="no-cache">
                o   <meta http-equiv="Pragma" CONTENT="no-cache">
·         Try to analyze how homebanking sites deal with it (some don’t deal with it at all);
 
Let me know if you have faced & solved this kind of problems!
1
0
14 Dec 2011
Copy Link
2025-11-03 12-56-18
Evert van der Zalm
 
MVP
Ruben,

The only thing I learned about the back buton, don't start with it :).

Don't know what you're trying to achieve, but if it's about a page the user isn't allowed to visit anymore, do this by code and redirections (catch the user in the preparation and check with something (session variable) if he is allowed in that page, if not use a destination).

Kind regards,
Evert
0
0
14 Dec 2011
Copy Link
2011-06-15 10-51-22
Joop Stringer
2011-07-23 17-17-55
Dung Che Tan
2
0
28 Dec 2011
Copy Link
2024-06-12 10-07-10
Daniel Martins
Definitely worth a try!

Thank you, Dung Che Tan.
0
0
30 Dec 2011
Copy Link
2013-03-14 12-00-25
Daniel Luz
Staff
Hi guys,

Sorry to revive an old thread, but recently we ran into a similar requirement so I'll share our approach in hopes it benefits someone :)

The situation we were trying to solve was going back to a stale page with outdated form data and repeating actions, which cause errors. For example, resubmitting a request that has in the meantime moved on in the process.
Another example is when the user logs out, then hits back and still gets a page, although he should be redirected to the login page.

First of all, I agree with the "don't mess with the Back button" approach. It's a standard button, and disabling it or making it do different things should be avoided.
So we didn't disable it.

What we did was this:
- Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
- Add a bit of Javascript to the page ready event to:
  - Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
  - If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else

This way, when you hit Back, the page ready event is triggered but the contents of the input is 'yes' because this page isn't fresh from the server (our JS set this value to 'yes' when it was previously rendered) so our JS now forces a refresh of the page, which should solve all our problems.
If the user logged out, the refresh will throw a security exception and send him to the login page, as expected.
If he submitted the form already, the refresh will update the form with the current data (and if the state is not editable, appropriate errors are shown/user is redirected).

Hope this is of some use. I attached an espace that contains an example implementation of this.

Cheers,
Daniel
BackButtonBrowserToPreparation.oml
6
0
31 Jul 2015
Copy Link
2017-07-06 09-31-00
Jasper Oudenaarden

Daniel Luz wrote:

Hi guys,

Sorry to revive an old thread, but recently we ran into a similar requirement so I'll share our approach in hopes it benefits someone :)

The situation we were trying to solve was going back to a stale page with outdated form data and repeating actions, which cause errors. For example, resubmitting a request that has in the meantime moved on in the process.
Another example is when the user logs out, then hits back and still gets a page, although he should be redirected to the login page.

First of all, I agree with the "don't mess with the Back button" approach. It's a standard button, and disabling it or making it do different things should be avoided.
So we didn't disable it.

What we did was this:
- Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
- Add a bit of Javascript to the page ready event to:
  - Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
  - If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else

This way, when you hit Back, the page ready event is triggered but the contents of the input is 'yes' because this page isn't fresh from the server (our JS set this value to 'yes' when it was previously rendered) so our JS now forces a refresh of the page, which should solve all our problems.
If the user logged out, the refresh will throw a security exception and send him to the login page, as expected.
If he submitted the form already, the refresh will update the form with the current data (and if the state is not editable, appropriate errors are shown/user is redirected).

Hope this is of some use. I attached an espace that contains an example implementation of this.

Cheers,
Daniel

The above solution doesn't work anymore in newest Chrome browser.


0
0
01 Jun 2018
Copy Link
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP

Like Evert said all those years ago: don't start with the back button :).

0
0
01 Jun 2018
Copy Link
2018-05-28 09-56-50
Filipe Silva

I have something like this and it works


SyntaxEditor Code Snippet

$(document).ready(function(){ 

history.pushState(null, null, document.URL);
window.addEventListener('popstate', function () {
    history.pushState(null, null, document.URL);
});
    
});
0
0
01 Jun 2018
Copy Link
2013-03-14 12-00-25
Daniel Luz
Staff

Talk about a post bump :)

So the solution I suggested is not for disabling the Back button. I would avoid that temptation at all cost. My solution is for forcing a refresh of the actual page that was in the browser history, not to redirect to a different one or force the user stay in the current one.

Jasper, if you're trying to use that approach for this purpose (not for disabling the Back button) and still find it's not working, post some more detail about the behavior you're seeing and any errors you're getting.

0
0
01 Jun 2018
Copy Link
2017-07-06 09-31-00
Jasper Oudenaarden

Daniel Luz wrote:

Talk about a post bump :)

So the solution I suggested is not for disabling the Back button. I would avoid that temptation at all cost. My solution is for forcing a refresh of the actual page that was in the browser history, not to redirect to a different one or force the user stay in the current one.

Jasper, if you're trying to use that approach for this purpose (not for disabling the Back button) and still find it's not working, post some more detail about the behavior you're seeing and any errors you're getting.

Yes @Daniel, not at all trying to disable the backbutton ;)

But your solution to reignite the screen preparation isn't working anymore. Be aware of that!

My problem/solution:

At a client we we're having this problem of entering the screen with a certain id and doing some Ajax stuff which then registers/holds the selected item id in a SessionVar. Important: This can then be another item/id then the one in de URL GET parameter. When navigating to an other OS app the SessionVar/Id is used to get the correct/same item loaded in an other context. Then came the tricky part......when using the OS navigation to go back to the previous app everything works fine of course. But when the user decides to use the back button instead, the original state (from the initial URL GET parameters) is then loaded :(

I found a way that perfectly works for me:

When clicking a next item in the screen I will update the SessionVar + the URL parameter as well via the following method:


The SetCorrectURL is a default OS RunJavascript action which contains the following code:

history.pushState({}, """", '"+ GetEntryURL.URL +"');

(https://developer.mozilla.org/en-US/docs/Web/API/History_API#The_pushState().c2.a0method)


In this way when in the next OS app/screen is navigating back (via browser back button), the correct URL is always loaded, without even to launch the preparation again (performance plus)!

Again....this worked for me and is not about disabling the browser back button or reigniting the preparation ;)



0
0
02 Jun 2018
Copy Link
2026-03-04 12-24-50
Ruben Bonito
 
MVP

Hello,

This might be a solution for you with a few small changes: https://www.outsystems.com/forge/component/2932/browsers-back-button-protection

KR,
Ruben Bonito

0
0
03 Jul 2018
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.