12

So the SMEs at my current place of employment want to try and disable the back button for certain pages. We have a page where the user makes some selections and submits them to be processed. In some instances they have to enter a comment on another page.

What the users have figured out is that they don't have to enter a comment if they submit the information and go to the page with the comment and then hit the back button to return to the previous page.

I know there are several different solutions to this (and many of them are far more elegant then disabling the back button), but this is what I'm left with. Is it possible to prevent someone from going back to the previous page through altering the behavior of the back button. (like a submit -> return false sorta thing).

Due to double posting information I can't have it return to the previous page and then move to the current one. I can only have it not direct away from the current page. I Googled it, but I only saw posts saying that it will always return to the previous page. I was hoping that someone has some mad kung foo js skills that can make this possible.

I understand that everyone says this is a bad idea, and I agree, but sometimes you just have to do what you're told.

Chris
  • 6,761
  • 6
  • 52
  • 67
kemiller2002
  • 113,795
  • 27
  • 197
  • 251
  • 2
    +1 in sympathy for having to DTWT sometimes. – Simon May 04 '11 at 09:23
  • 4GuysFromRolla did a thorough examination of "Disabling the Back Button." I recommend that you read that article, they also tell you why it will not work (in all scenarios). – Espo Sep 10 '08 at 16:17

15 Answers15

41

Don't do this, just don't. It's bad interface design and forces the user's browser to behave in a way that they don't expect.

I would regard any script that successfully stopped my back button from working to be a hack, and I would expect the IE team to release a security-fix for it.

The back button is part of their program interface, not your website.

In your specific case I think the best bet is to add an unload event to the page that warns the user if they haven't completed the form. The back button would be unaffected and the user would be warned of their action.

Keith
  • 150,284
  • 78
  • 298
  • 434
  • 1
    Keith is spot on. The 4 Guys article previously referenced even ends with: "After my exhaustive search I found that there is still no way of truly disabling the back button for all cases." Doh! I don't need to read two articles to read that last! – rp. Sep 10 '08 at 16:31
  • 1
    agreed Keith. We've been through roughly the same situation at my work and after a long time we realized it would have been easier to refactor the application to not need the back button disabled. – Jared Sep 10 '08 at 18:44
  • 1
    When I press the back button and the website drops a "Page no longer valid" error, I don't see this as unexpected, I realise I have done the wrong thing, I think most users would be OK with this. You feel guilty for trying to rewrite history. – Stuart Dobson Sep 26 '12 at 23:56
  • @StuartDobson - yes, and that's the standard way to do it. Users can still go back and keep going back, their browser just doesn't reload the pages. – Keith Sep 27 '12 at 07:12
5

Nah, you're doomed. Even if you pop the page up in some different browser and hid the back button, there's always the Backspace key.

The problem with marketing guys and analyst types is that some of them do not understand the fundamental concept of the web being stateless. They do not understand that the page is totally, totally unaware of the browser using it and absolute control of the browser is totally outside the capability of web pages.

The best way to discourage your users to hit the back button is to make sure that your page loses all its data when they press back, e.g., the comment page is the only point where the data can be saved, and if they do press the back button they have to do everything all over again (think along the lines of pragma: nocache).

Users will complain, sure, but they are the reason that this godforsaken requirement exists, right?

Jon Limjap
  • 94,284
  • 15
  • 101
  • 152
4

I've seen this before:

window.onBack = history.forward();

It is most definitely a dirty hack and, if at all possible, I would attempt to not disable the back button. And the user can probably still get around it quite easily. And depending on caching, there is no telling if the server code will be processed or if the cached page with JavaScript will run first.

So, yeah, use at your own risk :)

David Mohundro
  • 11,922
  • 5
  • 40
  • 44
  • Would your code break this "requirement"? "Due to double posting information I can't have it return to the previous page and then move to the current one. I can only have it not direct away from the current page" – Espo Sep 10 '08 at 16:21
  • I've used a web app that did that before and it was one of the most frustrating things ever. – Steven Benitez Nov 17 '10 at 17:08
  • Agreed, I hate sites that do this - I think it breaks the web. I also wasn't involved in the requirements on the project that used this particular technique :) – David Mohundro Nov 17 '10 at 21:25
  • The sample code makes no sense. It creates a new global variable called "onBack" and assigns "undefined" to it, as history.forward() has no return value. The idea might have been `window.onback = history.forward;`, (calling window.forward when the `onback` event fires - which would not work, as there is no `onback` event). The code does still works as as call to `history.forward()`, which sends the user back to the page he was on before clicking the back button... – Mira Weller Dec 22 '16 at 20:04
  • Otherwise, I agree with it being a bad idea ;-) – Mira Weller Dec 22 '16 at 20:04
4

I came up with a little hack that disables the back button using JavaScript. I checked it on chrome 10, firefox 3.6 and IE9:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<title>Untitled Page</title>
<script type = "text/javascript" >
function changeHashOnLoad() {
     window.location.href += "#";
     setTimeout("changeHashAgain()", "50"); 
}

function changeHashAgain() {
  window.location.href += "1";
}
// If you want to skip the auto-positioning at the top of browser window,you can add the below code:
window.location.hash=' ';
var storedHash = window.location.hash;
window.setInterval(function () {
    if (window.location.hash != storedHash) {
         window.location.hash = storedHash;
    }
}, 50);


</script>
</head>
<body onload="changeHashOnLoad(); ">
Try to hit the back button!
</body>
</html>
Maruthi
  • 13
  • 5
Yossi Shasho
  • 3,632
  • 31
  • 47
3

Do you have access to the server-side source code? If so, you can put a check on the first page that redirects to the second page if the information has been submitted already (you'll need to use sessions for this, obviously). At a former job, this is how we handled multi-step applications (application as in application for acceptance).

Brian Warshaw
  • 22,657
  • 9
  • 53
  • 72
2

Could you move the comment to the previous page and make it a required field there?

Disabling the back button will not work.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
2

Because of the security isolation of javascript in the browser, you cannot change what the back button does.

Perhaps you could store something in the user's session that indicates that a comment is needed, and have any page in the app that the user tries to load redirect to the comment page?

What if the user closes their browser when he/she gets tot he comment page?

I know that you have not been given a choice here, but since what they are asking for seems to be impossible...

Perhaps you could just not consider the item as completed until the user enters comments. Thus, you would need to keep track of both in-progress items and completed items, and make that distinction in the UI, but this might be the most robust method.

Or just put the comment field on the form page?

pkaeding
  • 36,513
  • 30
  • 103
  • 141
2

What the users have figured out is that they don't have to enter a comment if they submit the information and go to the page with the comment and then hit the back button to return to the previous page.

Then they are probably also smart enough to type 'no comment' into the comments field.

You can try to force people to add comments, but you will probably just end up with bad unusable software, annoyed users, and still not get comments. This is usually a good time to take a step back and reconsider what you are doing from the users' point of view.

Peter Hilton
  • 17,211
  • 6
  • 50
  • 75
  • 1
    This also just screams of some bad code. Why are people able to bypass the comment with a click of the back button? You don't solve bad code by hacking the user's browser. – Doug Moore Sep 17 '08 at 21:15
1

You should secure your application against double submission instead of breaking user interface to hide the bug.

Kornel
  • 97,764
  • 37
  • 219
  • 309
1

Disabling the back button seems kind of a "brute force" approach.

Another option would be that you could jump out to a modal dialog that doesn't have command buttons, walk users through the workflow, and close the dialog when the process is complete.

Guy Starbuck
  • 21,603
  • 7
  • 53
  • 64
0

You can prevent them from going back to the previous page. location.replace() replaces the current page's history entry with a new page, so...

page1.html: user clicks a link that goes to page2.html

page2.html: user clicks a link that calls location.replace('page3.html');

page3.html: user clicks back button and goes to page1.html

This may not fit well with doing a POST, but you could post the data to a web service via AJAX, then call location.replace()

Webveloper
  • 1,059
  • 10
  • 15
0

If you are starting a new web app from scratch, or you have enough time to rework your app, you can use JavaScript and AJAX to avoid the browser's history, back, and forward functions.

  • Open your app in a new window, either before or immediately after login.
  • If you wish, use window options to hide the nav bar (with the back and forward buttons).
  • Use AJAX for all server requests, without ever changing the window's location URL.
  • Use a simple web API to get data and perform actions, and render the app using JavaScript.
  • There will be only one URL in the window's history.
  • The back and forward buttons will do nothing.
  • The window can be closed automatically on logging out.
  • No information is leaked to the browser history, which can help with security.

This technique answers the question, but it also contradicts best practice in several ways:

  • The back and forward buttons should behave as expected.
  • An app should not open new browser windows.
  • An app should still function without JavaScript.

Please carefully consider your requirements and your users before using this technique.

Sam Watkins
  • 7,819
  • 3
  • 38
  • 38
0

I don't see this solution :

function removeBack(){
 window.location.hash="nbb";
 window.location.hash="";
 window.onhashchange=function(){window.location.hash="";}
}
Denis Chenu
  • 846
  • 2
  • 7
  • 22
0

There simply is no reliable way to do this. You cannot guarantee that 100% of the time you can stop the user from doing this.

With that in mind, is it worth going to extremely exotic solutions to disable "most" of the time? That's for you to decide.

Good luck.

Matt Dawdy
  • 19,247
  • 18
  • 66
  • 91
0

AS a simple solution: try this one. Insert an update panel and a button in there and use javascript to hide it and then press it on page load. Yes I understand that it will cause your page to post back on load and may not work if javascript is disabled but certainly will help you achieve a half decent response to the back button issue. Andy

Andy
  • 99
  • 9