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

[Tom]

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]

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

One idea I was toying with was too add a parameter to the URL
represented by history.previou s by it seems to be forbidden to try to
manually manipulate this value.

[Ian Hobson]

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

[Tom]

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 <ian.hob...@ntl world.comwrote:

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