Saturday, September 02, 2006

Intercept the web browser back button

While working on a (yet-to-released) JavaScript hack, I needed a method to intercept the browser back button for preventing users from leaving a web page, and hence the thread of control. AJAX programmers also need to support the back button when moving through sessions states on the same page. From what I can tell, the "normal" way to do this is by users link anchors. I wanted something simpler and more forceful. Here's a technique I found using Firefox (

var body = document.getElementsByTagName('body');
body[0].setAttribute("onunload", "backButtonDestroyer()");

function backButtonDestroyer() {
window.location = '';

Note: If someone has previously published technique (I couldn't find it), let me know and I'll link to you. Thanks.


nrg said...

Hello mate, have you checked when we try to exit the page (and we are logged in) it shows an alert asking if we really want to leave or stay in the page. I have never seen something like that but it got me curious on how it works. I never researched it but this post remembered me that.
Maybe instead of showing the alert you can force the user to stay in the page, or whatever you want to do.

If this got nothing to do with the topic i'm sorry, but if you have an idea how that works i would like to know (maybe 'onunload' event?).

btw i have been reading your blog for the past weeks and i must say it's very good, keep posting.


kuza55 said...

I think that breaking the back button isn't a great idea, because then you have your users unable to leave your application. An approach which doesn't break the back button, but also allows the user to go back to previous states, will probably be better. I haven't tried this idea, but it should theoretically work. It also pretty much relies on yoru whole AJAX app running from a single page, because it seems a bit clunky if you're sticking several window/session histories together, etc.

Firstly have the first page of your AJAX app as a page which simply redirects (NOT using a HTTP header or meta tag, but some Javascript) to your main AJAX page (for the moment)

If you store the window/AJAX history either on the server (which works well for applications like email where everytime the state changes more data has to be requested from the server) or as a cookie, obviously cookie storage is limited, but if you don't need a long history, then it should be viable.
A hybrid approach would also work, if you told the server whenever you were communicating with it, but also stored the other history (with timestamps so it could be merged), would probably work as well.

And when the user presses the back button, they get sent to your blank page, which will have serverside code which merges the serverside/cookie history and then extracts the page the user wants to go to and then stores that state somewhere; either by setting another cookie, or by having the next page print the value into the page from the server side, whatever, and it then redirects them to the main page, where it loads the new (the previous) state.

It does seem a bit complex/overkill, but the system doesn't break any current browser functionality and does let you go back to previous sites/pages....

Another idea would be to actually provide some back/formward buttons in your UI (which would be much easier considering it could just be stored in a Javascript array) so that the user doesn't feel inclined to use the browser's buttons.

So yeah, while it is a bit over the top, I hope it is useful, or gives some ideas, or something.....

Jeremiah Grossman said...

Hi nrg,

Thanks for the kind words. I'll try to keep the quality content coming. Been shooting for a decent post every day or two.

I'll have a look a meebo and see what I find. Another one that just didn't occur to me was blogger! They have features that do back and reload button capturing. Though piling through all that JS code is not appealing. :)

Godzy said...

Hi Jeremiah ,

I think the following post in my blog will have something for u.. please have a look


Nathan said...

look at the onbeforeunload event

ARTI AJANS said...

This is working true. Wonderful! Thanks you too much...

dış cephe said...

Great .Thanks a lot.