Why is history.back doing a reload with Chrome and Safari?

[ViLco]

I'm using Ajax and I have pages with many input tags where user can insert
data. My js function edit some input tags as well, using
document.getElementById("elementname").value = myvalue
After having set data on page1 and clicking a button, a js function will
redirect the browser to page2 where the user will choose between an OK and a
Cancel button. The OK button calls a JS function that does some work and
then redirects the browser back to page1 via a history.back() command.
When this happens, in FF and IE8 the page page1 will show itself just as we
left it: with all of the data still in the input tags, since these browsers
cache the page when moving to another page and then, when getting back, they
show the page as they cached it.
In Safari and Chrome, instead, the history.back() command issues a *reload*
of the page from the server, so all of the input tags values get back to the
value they had before the user and JS function edited them. All user
inserted values are lost along with all the values I had programmatically
set in page1 via JS functions.
I need the data that was entered in page1, and I'm at a loss with these two
Webkit based browsers.
I searched the web and found many people talking about this issue, including
people who said they solved the issue in many ways: some suggest to use
history.go(-1) instead of history.back(), some suggest to use
history.back(1), others suggest to create a JS function goback() which does
a history.go(-1) and call that function instead of history.go(.1) directly,
but none of that works. I have seen that many of these persons talk about
anchors, like this:
<a href="#" onClick="history.go(-1)">go back</a>
This is not my case since I'm directing the browser back in a programmatical
way, which is: from my JS functions, not in an anchor like the above one.

Anyone has a clue about how to prevent this reload?

Chrome version: 14.0.835.202 (Official build 103287) m
Safari version: 5.1 (7534.50)

 

[ViLco]

This is not my case since I'm directing the browser back in a
programmatical way, which is: from my JS functions, not in an anchor
like the above one.
Anyone has a clue about how to prevent this reload?

I found out this on webkit.org but it isn't very informative.

http://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/

The only really technical article is the next one but it is specific to
onunload only and I have no onunload calls here.
So, I'm stuck with this "basics" article which says that webkit doesn't
cache unuseful pages, complex pages and secure pages. I checked but I have
no unuseful pages, no active plugins, no frames and no https.
I'm stuck.

 

[Tom de Neef]

I'm using Ajax and I have pages with many input tags where user can insert
data. My js function edit some input tags as well, using
document.getElementById("elementname").value = myvalue
After having set data on page1 and clicking a button, a js function will
redirect the browser to page2 where the user will choose between an OK and
a Cancel button. The OK button calls a JS function that does some work and
then redirects the browser back to page1 via a history.back() command.
When this happens, in FF and IE8 the page page1 will show itself just as
we left it: with all of the data still in the input tags, since these
browsers cache the page when moving to another page and then, when getting
back, they show the page as they cached it.
In Safari and Chrome, instead, the history.back() command issues a
*reload* of the page from the server, so all of the input tags values get
back to the value they had before the user and JS function edited them.
All user inserted values are lost along with all the values I had
programmatically set in page1 via JS functions.

Anyone has a clue about how to prevent this reload?

What you could do is create your page2 as a second window within the context
of the main page. When it is closed, your main page is still there.
Tom

 

[Andreas Bergmaier]

I'm using Ajax and I have pages with many input tags where user can insert
data. My js function edit some input tags as well, using
document.getElementById("elementname").value = myvalue
After having set data on page1 and clicking a button, a js function will
redirect the browser to page2 where the user will choose between an OK and a
Cancel button. The OK button calls a JS function that does some work and
then redirects the browser back to page1 via a history.back() command.

For what do you need a second page? Why don't you just show the confirm
dialogue on page1? There are lots of ways to do that, you even should be
able to do this with Ajax as you're already used to it, if you need to
send/fetch server data to/from the server.
If there is a good reason for a second page, just post your form data to
page2 instead of "redirecting with a js function". Page2 then could be
served as a prefilled, hidden form with your "OK" button to submit it.
Bergi

 

[ViLco]

For what do you need a second page? Why don't you just show the
confirm dialogue on page1?

I'd love to use a confirm() but page2 shows those 2 buttons and many more
things, both text and graphics.

There are lots of ways to do that, you
even should be able to do this with Ajax as you're already used to
it, if you need to send/fetch server data to/from the server.
If there is a good reason for a second page, just post your form data
to page2 instead of "redirecting with a js function".

I have to use that JS function since I need to do many things based on the
user input in page1, that function does all this and, under certain
conditions, must throw page2. Under other conditions it throws another page,
under other conditions it doesn't throw any page. Page1 has its own data and
the same is true for page2, there are two sets of data and when I'm in
page1, before calling the JS function, I do not know if and which page I'll
throw.
What do you mean with "post your form data to page2"?

Page2 then could be served as a prefilled, hidden form with your "OK"
button to
submit it.

This is interesting, as is Tom's suggestion.