How can we stop IE from executing javascript on a back button click

Discussion in 'Javascript' started by Tom, Nov 14, 2007.

  1. Tom

    Tom Guest

    Basically I have a page that I load with 10 input fields. If users
    have JS enabled I want to hide 5 of these fields so as to reduce
    clutter. If the user needs these extra fields an "Add" button can be
    used to display the hidden fields one by one.

    Once the fields a filled in the user submits them for validation and
    if there are any error They can "Go back" to make some changes. The
    whole process works great in FF & Opera but IE lets me down because if
    you use the Browser "Back" button the Javavscript gets executed even
    though it should be loaded out of cache.

    An simple example to the my problem across can be found at
    http://tommydiy.freehostingnow.com/backcache.html

    Any suggestion greatly appreciated.
    Tom
     
    Tom, Nov 14, 2007
    #1
    1. Advertising

  2. Tom

    Tom Guest

    One idea I was toying with was too add a parameter to the URL
    represented by history.previous by it seems to be forbidden to try to
    manually manipulate this value.
     
    Tom, Nov 14, 2007
    #2
    1. Advertising

  3. Tom

    Ian Hobson Guest

    Re: How can we stop IE from executing javascript on a back buttonclick

    Hi Tom,

    Tom wrote:
    > Basically I have a page that I load with 10 input fields. If users
    > have JS enabled I want to hide 5 of these fields so as to reduce
    > clutter. If the user needs these extra fields an "Add" button can be
    > used to display the hidden fields one by one.

    A good, helpful way to use JS.
    >
    > Once the fields a filled in the user submits them for validation and
    > if there are any error They can "Go back" to make some changes. The
    > whole process works great in FF & Opera but IE lets me down because if
    > you use the Browser "Back" button the Javavscript gets executed even
    > though it should be loaded out of cache.
    >
    > An simple example to the my problem across can be found at
    > http://tommydiy.freehostingnow.com/backcache.html
    >
    > Any suggestion greatly appreciated.
    > Tom
    >

    Hi Tom,

    I think it is a good idea NOT to ask your users to go back - they often
    find there is no data in the fields they entered when they do go back
    and they have to enter it all in again.

    And that is a way to piss off your users in a major way. In a business
    context, it also upsets the person paying their wages.

    So....

    Record the status of the open/closed fields in a hidden field, so it is
    sent with the POST.

    After validation, the script handling the POST should either

    a) If the data is valid, update the database and use a "location" header
    to redisplay the data in show mode. This produces a display of the data
    stored, not a redisplay of the data the user just sent).

    b) If the data is invalid, build the next (response) screen exactly as
    on initial "show" request, but including all the error messages set up
    in validation and the data you have from the POST (instead of data from
    the database read). It is easy to use the same code so this is "no cost".

    OK - I am assuming you show the data to the users with a "Edit" button,
    so they have confidence they have not changed anything if the don't
    click "Edit". I find this is a good idea also :)

    When you send the response the "onload" event can open or close the
    fields as required - you have the data to set a parameter for this.

    That way the users don't have to go back when they make an error.

    And ALL error messages are shown on the screen - not one at a time or on
    another screen.

    And they can be near the field that is in error.

    But wait - there is more...

    If your visitor goes on elsewhere and comes back to the response page
    they will NOT be presented with the warning about repeating the POST!
    (To get that they would have to go back FROM the history list. And there
    is no reason for them to do that.) A simple back fro the response
    screen reloads it again. This removes possible double updates which
    could damage the database, without inconveniencing your users at all.

    And as your final bonus... :)

    You also avoid many character set conversion problems. You won't find
    that the show of saved data does not include the same character
    conversions as you have stored in your database. I.e. the "show" after
    save is different from the "show" of freshly read data from the database.

    Until I worked out the location header trick I was forever getting back
    slashes doubled up every edit, and £ characters would gain A-acutes -
    but these problems did not appear on the response page, only later.

    Regards

    Ian
     
    Ian Hobson, Nov 23, 2007
    #3
  4. Tom

    Tom Guest

    Re: How can we stop IE from executing javascript on a back buttonclick

    Thanks for your reply Ian,

    I will digest your recommendations and see what I come up with.

    Thanks for the extensive input. You are really selling your point :p

    Tom

    On Nov 23, 4:42 pm, Ian Hobson <> wrote:
    > Hi Tom,
    >
    > Tom wrote:
    > > Basically I have a page that I load with 10 input fields. If users
    > > have JS enabled I want to hide 5 of these fields so as to reduce
    > > clutter. If the user needs these extra fields an "Add" button can be
    > > used to display the hidden fields one by one.

    >
    > A good, helpful way to use JS.
    >
    > > Once the fields a filled in the user submits them for validation and
    > > if there are any error They can "Go back" to make some changes. The
    > > whole process works great in FF & Opera but IE lets me down because if
    > > you use the Browser "Back" button the Javavscript gets executed even
    > > though it should be loaded out of cache.

    >
    > > An simple example to the my problem across can be found at
    > >http://tommydiy.freehostingnow.com/backcache.html

    >
    > > Any suggestion greatly appreciated.
    > > Tom

    >
    > Hi Tom,
    >
    > I think it is a good idea NOT to ask your users to go back - they often
    > find there is no data in the fields they entered when they do go back
    > and they have to enter it all in again.
    >
    > And that is a way to piss off your users in a major way. In a business
    > context, it also upsets the person paying their wages.
    >
    > So....
    >
    > Record the status of the open/closed fields in a hidden field, so it is
    > sent with the POST.
    >
    > After validation, the script handling the POST should either
    >
    > a) If the data is valid, update the database and use a "location" header
    > to redisplay the data in show mode. This produces a display of the data
    > stored, not a redisplay of the data the user just sent).
    >
    > b) If the data is invalid, build the next (response) screen exactly as
    > on initial "show" request, but including all the error messages set up
    > in validation and the data you have from the POST (instead of data from
    > the database read). It is easy to use the same code so this is "no cost".
    >
    > OK - I am assuming you show the data to the users with a "Edit" button,
    > so they have confidence they have not changed anything if the don't
    > click "Edit". I find this is a good idea also :)
    >
    > When you send the response the "onload" event can open or close the
    > fields as required - you have the data to set a parameter for this.
    >
    > That way the users don't have to go back when they make an error.
    >
    > And ALL error messages are shown on the screen - not one at a time or on
    > another screen.
    >
    > And they can be near the field that is in error.
    >
    > But wait - there is more...
    >
    > If your visitor goes on elsewhere and comes back to the response page
    > they will NOT be presented with the warning about repeating the POST!
    > (To get that they would have to go back FROM the history list. And there
    > is no reason for them to do that.) A simple back fro the response
    > screen reloads it again. This removes possible double updates which
    > could damage the database, without inconveniencing your users at all.
    >
    > And as your final bonus... :)
    >
    > You also avoid many character set conversion problems. You won't find
    > that the show of saved data does not include the same character
    > conversions as you have stored in your database. I.e. the "show" after
    > save is different from the "show" of freshly read data from the database.
    >
    > Until I worked out the location header trick I was forever getting back
    > slashes doubled up every edit, and £ characters would gain A-acutes -
    > but these problems did not appear on the response page, only later.
    >
    > Regards
    >
    > Ian
     
    Tom, Nov 27, 2007
    #4
    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. Purvi T
    Replies:
    0
    Views:
    864
    Purvi T
    Oct 19, 2004
  2. sylvia sil
    Replies:
    1
    Views:
    625
    Curt_C [MVP]
    Dec 29, 2004
  3. Amelyan
    Replies:
    4
    Views:
    7,719
    sajidali3387
    Dec 9, 2011
  4. Amy
    Replies:
    0
    Views:
    997
  5. Replies:
    0
    Views:
    302
Loading...

Share This Page