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

Discussion in 'Javascript' started by ViLco, Oct 19, 2011.

  1. ViLco

    ViLco Guest

    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, Oct 19, 2011
    #1
    1. Advertising

  2. ViLco

    ViLco Guest

    ViLco wrote:

    > 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.
    ViLco, Oct 19, 2011
    #2
    1. Advertising

  3. ViLco

    Tom de Neef Guest

    "ViLco" <> schreef in bericht
    news:j7m2ao$6ci$...
    > 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
    Tom de Neef, Oct 19, 2011
    #3
  4. ViLco schrieb:
    > 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
    Andreas Bergmaier, Oct 19, 2011
    #4
  5. ViLco

    ViLco Guest

    Andreas Bergmaier wrote:

    >> 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?


    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.
    ViLco, Oct 20, 2011
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gen_tricomi
    Replies:
    2
    Views:
    737
    gen_tricomi
    May 23, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,842
    Smokey Grindel
    Dec 2, 2006
  3. Paul Hale
    Replies:
    0
    Views:
    293
    Paul Hale
    Sep 4, 2008
  4. DarthOptimus
    Replies:
    1
    Views:
    153
    Dr John Stockton
    Jun 8, 2006
  5. Replies:
    2
    Views:
    293
    nutso fasst
    Oct 17, 2006
Loading...

Share This Page