Firefox 3 doesn't allow 'Back' to a form if the form result in a redirect last time.

Question

Greetings,

Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session 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 relevant page.

This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?

Alexey

EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.

To quote:

Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:

a) A META header - Not recommended, and has some problems b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")

The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).

Answer 1

I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?

Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.

Answer 2

Its possibly in aide to eliminate repeated actions.

A lot of ways people do things is

page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.

Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.

Instead, firefox presumes the server sent a redirect header for a good reason.

Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.

( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )

Answer 3

I'm strongly in favor for the Firefox behaviour.

The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.

Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.

If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.

Answer 4

You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.

This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.

Answer 5

In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1