Firefox 3 does not allow "Back" to the form if the form results in a redirect the last time
Hello,
Here is the problem I am having. I have a page that is redirected directly to another page on the first visit. If the user clicks back, the page behaves differently and displays content instead (session tracking IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the corresponding page.
This works well in IE7, but Firefox 3 won't let me click "back" on the page that caused the redirect. I guess it does this to prevent the typical back -> redirect loop again that frustrates so many users. Any ideas on how I can override this behavior?
Alexei
EDIT: The page we are redirecting to is an external site over which we have no control. Server side redirects won't work because it won't create a back button in the browser.
Quote:
Some people on the thread talk about server side redirection and redirect headers (same thing) ... keep in mind that we need to redirect client side, which can be done in two ways:
a) META Header - Not recommended and has some problems b) Javascript, which can be executed in at least three ways ("location", "location.href" and "location.replace ()")
Server side redirects will not and should not activate the back button and cannot display the typical "You will be redirected now" page ... so this is not good (this is what we are doing at the moment, in fact .. where are you you are immediately redirected to the "lucky" page).
source to share
You can work around this by creating an iframe and storing the page state in the form field in the iframe before doing the redirect. All browsers preserve iframe form fields.
This page has a really good description of how to make it work. This is the same method that Google Maps uses when you click on map search results.
source to share
I think the Mozilla team is taking a step in the right direction by breaking this particularly annoying pattern. Finding a path around this somehow misses the point, does it?
Instead of redirecting on the first encounter, you can simply make your page visually different when the user first hits it. Should be easy enough on the server side since you already have code to make this distinction.
source to share
I am a strong proponent of Firefox behavior.
The easiest way to redirect is to send the server HTTP 302 status code + Location header back to the client. Thus, the client (usually the browser) will not put the request URI in its history, but will simply send the same request to the secure URI.
Now it seems that Firefox has started to apply bevaviour also for server responses that try to redirect eg. on the Javascript onload event.
If you want to prevent the browser from displaying the page, I believe the best solution is that the server does not send the page in the first place.
source to share
Perhaps this will help eliminate repetitive actions.
Many people do things
page 1 → [Action] → page 2 → redirect to page 2 without action parameters.
Now, if you were allowed to hit the back button in this situation and visit the page without redirecting, the action would be blindly re-executed.
Instead, firefox assumes that the server sent the redirect header for a good reason.
Even though you have, however, noted that you have content delivered after the redirect header, sending the redirect header (in php at least) does not complete execution, so in theory if you want to use a redirect request, get the page. doing strange things.
(I get around this by having all of our redirects done through the same function call where I call explicit completion immediately after the redirect because people when coding think this is how it goes)
source to share