Callback Functions for Back and Forward Buttons
I had this random thought today while using a page with a lot of AJAX. We all know that you can't use the browser's Back and Forward buttons when using web applications and pages with Post data. Most users aren't aware of that and will use them anyway, and that can mess up a multi-page form, and other things.
Here is an idea I had to fix it. What if there could be callback functions for the buttons. Say, browser_back() and browser_forward(). If those JavaScript functions exist, then the browser will call them instead of going back a page which could break the session. Then, the website can handle those calls in a way so that the form or application wouldn't do something unpredictable. What do you think?
decibel.places posted this at 17:49 — 23rd August 2008.
He has: 1,494 posts
Joined: Jun 2008
Maybe possible with Ffox and Opera - does IE provide an API to the toolbar buttons?
Other possibilities are cookies and $_SESSION variables...
greg posted this at 17:59 — 23rd August 2008.
He has: 1,581 posts
Joined: Nov 2005
You would have thought by now that this issue would have been resolved within the browsers. Even a more stable ability to not cache post data would be useful.
The other alternative is using a session or other means to determine if the data is old/has been used already. That way the code wont get post data and do what it would with it had it been the first run or data is the same. Of course that's not always possible, depending on the data usage.
And is exactly why I only ever use POST and GET data on a page that isn't processed in the users browser.
No output at all, get post or get data, do calculations (or whatever) with it then redirect the user to a set of results or next form page or whatever (or back to the previous page with error report)
decibel.places posted this at 18:14 — 23rd August 2008.
He has: 1,494 posts
Joined: Jun 2008
Well, assuming that the user follows the expected procedure, that is fine.
One of the profoundest experiences I had was letting a class of 3rd graders loose on a JS quiz app I was developing - talk about unexpected input!
Yes, using POST/GET on a submission page is a good practice, but the question here is what happens to the AJAX data if the user hits the browser back button?
John_audson posted this at 10:37 — 30th August 2008.
They have: 53 posts
Joined: Aug 2008
Firefox: The technique to make History Management work in Firefox is based on polling. When the location hash (the # in the url) is changed, the FF history engine adds a new entry in the window.history array. HistMan looks for a change in the hash and when there’s a change it executes a callback function of which the hash refers to. The interval for polling is set at 200 ms. This means that there’s a change there’s a delay of 200 ms before the callback function is called. Lowering the interval would decrease this delay but would increase the processor usage on the client-side.
IE6+/Opera9: When HistMan is loaded it creates an hidden iframe. To add a new history entry to the history engine, we change the iframe’s location.href to a url including a GET request. The GET request sets some javascript that’s attached to the onload event of the body of the page that’s loaded into the iframe. The javascript then executes the callback function and changes the hash of it’s parent. When the location.href is changed, a new history entry is added, so that makes the back and forward navigation buttons work.
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.