Form fields don't persist after, form submit, browser back

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have the following problem under Internet Explorer only:

1. User fills out form data (myform.php) and clicks a button that fires
2. myFunction() spawns a "hello, world" popup page via
3. myFunction() submits the main page's form via document.form.submit()
5. User closes popup window and clicks browser's Back button to return
to form entry page
6. All the form data that the user had filled out is now blank (back to

If you take step 2) out of the equation, then the form data that the
user submitted is still there in step 6).  This is the behavior I want,
and I am mystified as to why the addition of causes a
difference under IE.  What could be going on here?  If it were a
cache-related issue, I wouldn't expect step 2) to have any bearing on
the situation.

Below is a single PHP file you can save to see the problem for
yourself.  As an aside, the same thing happens if you write the
equivalent logic in perl, but in a straight HTML/javascript version,
there is no problem.

Thanks for any pointers,


<title>PHP Version</title>
if ($_REQUEST['Phase'] == 'Summary')
<p><b>Form Submitted</b></p>
<p>This is the post-submit version of the form...</p>
<script language="javascript">
function submitForm()
  if (document.form1.popup[0].checked)
    var popup ='', 'popup', 'width=200,height=200')
    popup.document.write('<html><body><p><b>PHP version:</b><br>Close
me, then use browser Back button and notice that your form fields are
<p>This is the pre-submit version of the form...</p>
  <form name="form1" action="" method="get">
    Text 1: <input type="text" size="12" name="text1"><br>
    <input type="radio" name="popup" value="show"> Open Popup
    <input type="radio" name="popup" value="noshow" CHECKED> No
    <input type="button" name="Submit" value="Submit"
    <input type="hidden" name="Phase" value="Summary">

Re: Form fields don't persist after, form submit, browser back

On Tue, 2006-03-21 at 11:40 -0800, wrote:
Quoted text here. Click to load it

I would categorize this as a browser issue, rather than a PHP problem.
Nonetheless, a possible workaround may be to save the submitted form
data in session variables, and refill the form using the session data.

You should still prevent caching of the original page for this to work,
however. Microsoft recommends using the Expires header (header('Expires:
-1'); or <META HTTP-EQUIV="Expires" CONTENT="-1">).

Re: Form fields don't persist after, form submit, browser back

I agree that it's most generally a browser/CGI implementation issue,
but I was hoping some fellow PHP travellers had encountered the issue
or could shed some light on why it happens in my simple example.
(That's assuming others can readily reproduce the behavior, which may
not be the case if server settings are the culprit here.)

It's true that I can get around the problem with additional code
overhead.  However, I'm hoping for pointers about why this happens at
all, whether it's actually expected behavior, and how caching/HTTP
header info could be coming into play here when the behavior seems to
be controlled by DOM-related activity alone (

Thanks for the ideas--hoping for others as well,

Re: Form fields don't persist after, form submit, browser back

Kimmo Laine wrote:
Quoted text here. Click to load it

Unless next_page.php generates PHP, the script with this include will
only get HTML.

Quoted text here. Click to load it


    if (isset($_GET['foo'])) {
      echo '<?php echo $_GET[\'foo\']; ?>';
    } else {
      echo '<?php echo \'Not available\'; ?>';

File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

Re: Form fields don't persist after, form submit, browser back

Good info, though it doesn't seem to shed any light on why Internet
Explorer seems to exhibit different caching behavior depending on
whether or not a window was spawned via prior to form

I am not using sessions at the PHP level and would rather not introduce
that across my code base just for this, so the session-related material
probably isn't an answer for me.

The solution I am going to pursue is to manually write out a
"Last-Modified" HTTP header with the last-modified time of the script
itself.  This definitely works around the apparent IE bug that I
described above, but it may cause me other grief that I haven't
discovered yet.

Thanks for all the advice,

Site Timeline