Raise your hand if you have ever wanted to disable the browser's BACK button

[Tony Marston]

If the use of the browser's BACK button is interfering with the operation of
your web application then take a look at this article entitle "Back Button
Blues"

http://www.tonymarston.co.uk/php-mysql/backbuttonblues.html

--
Tony Marston

http://www.tonymarston.net

[Chung Leong]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

I don't understand your argument against using the humble hidden. The
bandwidth disadvantage is negligible. And you need to do a access check on
the initial GET anyway, doing it again in the subsequent POST can't be that
hard.

Uzytkownik "Tony Marston" <tony@NOSPAM.de mon.co.uk> napisal w wiadomosci
news:c0r3nl$5vh $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> If the use of the browser's BACK button is interfering with the operation[/color]
of[color=blue]
> your web application then take a look at this article entitle "Back Button
> Blues"
>
> http://www.tonymarston.co.uk/php-mys...ttonblues.html
>
> --
> Tony Marston
>
> http://www.tonymarston.net
>
>
>[/color]

[Tony Marston]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

On some screens the number of hidden fields could be quite large, which
means that the document will take longer to download as well as retransmit.
Those of you who say that document size is not a problem are being totally
inconsiderate to those users who do not have a broadband connection.

Some of this data may also have security implications, so it is not a good
idea to send it across the net within the body of the HTML document as it
can be seen by anyone, especially by someone with nefarious intent. It is
better to keep such data on the server.

That is my humble opinion, for what it's worth.

Tony Marston

http://www.tonymarston.net

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:gKidnVnJhP Lb9Kzd4p2dnA@co mcast.com...[color=blue]
> I don't understand your argument against using the humble hidden. The
> bandwidth disadvantage is negligible. And you need to do a access check on
> the initial GET anyway, doing it again in the subsequent POST can't be[/color]
that[color=blue]
> hard.
>
> Uzytkownik "Tony Marston" <tony@NOSPAM.de mon.co.uk> napisal w wiadomosci
> news:c0r3nl$5vh $1$8302bc10@new s.demon.co.uk.. .[color=green]
> > If the use of the browser's BACK button is interfering with the[/color][/color]
operation[color=blue]
> of[color=green]
> > your web application then take a look at this article entitle "Back[/color][/color]
Button[color=blue][color=green]
> > Blues"
> >
> > http://www.tonymarston.co.uk/php-mys...ttonblues.html
> >
> > --
> > Tony Marston
> >
> > http://www.tonymarston.net
> >
> >
> >[/color]
>
>[/color]

[Jason]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

"Tony Marston" <tony@NOSPAM.de mon.co.uk> wrote in message news:<c0r3nl$5v h$1$8302bc10@ne ws.demon.co.uk> ...[color=blue]
> If the use of the browser's BACK button is interfering with the operation of
> your web application then take a look at this article entitle "Back Button
> Blues"
>
> http://www.tonymarston.co.uk/php-mys...ttonblues.html[/color]

I totally understand not wanting to let users resubmit forms by using
the back button or hitting reload when something is going slowly.

The simplest way around it I've thought of is to put a counter in
$_SESSION. Every time any page loads, the counter is incremented.
The form page has a hidden field equal to $_SESSION['counter'] + 1.
When submitting, if the current $_SESSION['counter'] and
$_POST['counter'] don't match, nothing is done.

Not as cool as a program stack, granted. :)

[John Dunlop]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Tony Marston wrote:
[color=blue]
> http://www.tonymarston.co.uk/php-mys...ttonblues.html[/color]

It looks as if you're confused about the distinction between history
mechanisms and browser caches (RFC2616, sec. 13.13); in short, they
ain't one and the same.

I'm firmly sitting on my hands.

--
Jock

[Tony Marston]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button


"John Dunlop" <john+usenet@jo hndunlop.info> wrote in message
news:MPG.1a9c73 18a99a77e098969 7@News.Individu al.NET...[color=blue]
> Tony Marston wrote:
>[color=green]
> > http://www.tonymarston.co.uk/php-mys...ttonblues.html[/color]
>
> It looks as if you're confused about the distinction between history
> mechanisms and browser caches (RFC2616, sec. 13.13); in short, they
> ain't one and the same.[/color]

I never said they are the same, which is why I have a separate paragraph
explaining each one. Unless the user clears his cache in the middle of a
session then everything in the history is also is also in the cache, but
everything in the cache may not be in the history.

Unless you know better, of course ...
[color=blue]
> I'm firmly sitting on my hands.[/color]

You'll get a lot of work done that way

--
Tony Marston

http://www.tonymarston.net

[John Dunlop]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Tony Marston wrote:

[About the explanation of history mechanisms and browser caches in

http://www.tonymarston.co.uk/php-mysql/backbuttonblues.html]

[color=blue]
> I never said they are the same, which is why I have a separate paragraph
> explaining each one.[/color]

There is no explanation of browser caches in the paragraph following
the subhead "Browser Cache". Are they explained elsewhere?

The explanation of history stacks, following the subhead "Browser
History", could be misleading: a history stack might not contain "all
pages visited"; if, say, I visit three webpages, go back twice, then
visit a new webpage, my history stack won't contain all previously
visited webpages. Donning my pedant hat for a moment, the term
"list" is used to describe how browser history mechanisms store
information; mightn't the term "stack" be more fitting? Or, I'd
suggest, at least, in passing, mention the term "stack".

Also, will you provide an URL to a document which claims that
accessing a file from the history stack ever caused any client to
make an HTTP request? I tried searching, without success. I'm just
curious, because that would be a truly silly way to engineer a
history mechanism.

Perhaps it'd be better to leave the explanation of those browser
features up to the sufficiently explanative documents already
publicly available.
[color=blue]
> Unless the user clears his cache in the middle of a session then everything
> in the history is also is also in the cache,[/color]

No; not necessarily. Uncacheable files might be in the history
stack, whilst not in the browser cache.
[color=blue]
> but everything in the cache may not be in the history.[/color]

Indeed.
[color=blue]
> Unless you know better, of course ...[/color]

I'd recommend you make up your own mind:

| History mechanisms and caches are different. In particular history
| mechanisms SHOULD NOT try to show a semantically transparent view
| of the current state of a resource. Rather, a history mechanism is
| meant to show exactly what the user saw at the time when the
| resource was retrieved.
|
| By default, an expiration time does not apply to history
| mechanisms. If the entity is still in storage, a history mechanism
| SHOULD display it even if the entity has expired, unless the user
| has specifically configured the agent to refresh expired history
| documents.
-- RFC2616, sec. 13.13, http://www.ietf.org/rfc/rfc2616.txt

My advice? Accept this "interferen ce", and stop trying to do the
impossible.

--
Jock

[Tony Marston]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button


"John Dunlop" <john+usenet@jo hndunlop.info> wrote in message
news:MPG.1a9ca6 5ee337183998969 8@News.Individu al.NET...[color=blue]
> Tony Marston wrote:
>
> [About the explanation of history mechanisms and browser caches in
> http://www.tonymarston.co.uk/php-mys...tonblues.html]
>[color=green]
> > I never said they are the same, which is why I have a separate paragraph
> > explaining each one.[/color]
>
> There is no explanation of browser caches in the paragraph following
> the subhead "Browser Cache". Are they explained elsewhere?[/color]

The cache is where the complete contents of the page is stored so that the
next time the same page is requested it is retrieved from the cache instead
of downloaded from the server. I did not supply complete details about the
caching mechainsim as it is not germaine to the issue under discussion.
[color=blue]
> The explanation of history stacks, following the subhead "Browser
> History", could be misleading: a history stack might not contain "all
> pages visited"; if, say, I visit three webpages, go back twice, then
> visit a new webpage, my history stack won't contain all previously
> visited webpages. Donning my pedant hat for a moment, the term
> "list" is used to describe how browser history mechanisms store
> information; mightn't the term "stack" be more fitting? Or, I'd
> suggest, at least, in passing, mention the term "stack".[/color]

The article is about using the browser's BACK button which is about moving
backwards through the browser's history. The fact that subsequent forward
movement may remove items from history is not germaine to the issue.
[color=blue]
> Also, will you provide an URL to a document which claims that
> accessing a file from the history stack ever caused any client to
> make an HTTP request? I tried searching, without success. I'm just
> curious, because that would be a truly silly way to engineer a
> history mechanism.[/color]

If you visit a page that exists in your browser's cache then your browser
will attempt to serve it from cache instead of re-issuing the request to the
server. However, the effects of the browser's cache can be turned off,
either by adjusting settings in your browser or by the page author inserting
settings in the document. Therefore it is possible to visit a page in the
history stack and issue a fresh HTTP request.
[color=blue]
> Perhaps it'd be better to leave the explanation of those browser
> features up to the sufficiently explanative documents already
> publicly available.
>[color=green]
> > Unless the user clears his cache in the middle of a session then[/color][/color]
everything[color=blue][color=green]
> > in the history is also is also in the cache,[/color]
>
> No; not necessarily. Uncacheable files might be in the history
> stack, whilst not in the browser cache.
>[color=green]
> > but everything in the cache may not be in the history.[/color]
>
> Indeed.
>[color=green]
> > Unless you know better, of course ...[/color][/color]

My document only contains that amount of information which is relevant to
the use of the BACK button. Everything else is superfluous.
[color=blue]
> I'd recommend you make up your own mind:
>
> | History mechanisms and caches are different. In particular history
> | mechanisms SHOULD NOT try to show a semantically transparent view
> | of the current state of a resource. Rather, a history mechanism is
> | meant to show exactly what the user saw at the time when the
> | resource was retrieved.
> |
> | By default, an expiration time does not apply to history
> | mechanisms. If the entity is still in storage, a history mechanism
> | SHOULD display it even if the entity has expired, unless the user
> | has specifically configured the agent to refresh expired history
> | documents.
> -- RFC2616, sec. 13.13, http://www.ietf.org/rfc/rfc2616.txt
>
> My advice? Accept this "interferen ce", and stop trying to do the
> impossible.
>
> --
> Jock[/color]

I am not trying to do the impossible. That is the mechanism that I currently
use so it is not impossible. I am merely sharing my technique with the rest
of the world in case anybody is interested. Obviously you are not. Big deal.

--
Tony Marston

http://www.tonymarston.net

[Jochen Daum]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Hi !

On Tue, 17 Feb 2004 22:30:26 -0000, John Dunlop
<john+usenet@jo hndunlop.info> wrote:
[color=blue]
>Tony Marston wrote:
>[/color]
(...)[color=blue]
>
>Also, will you provide an URL to a document which claims that
>accessing a file from the history stack ever caused any client to
>make an HTTP request? I tried searching, without success. I'm just
>curious, because that would be a truly silly way to engineer a
>history mechanism.[/color]

If you use IE and write down what you experience I beleive you would
have such a document.

HTH, Jochen
--
Jochen Daum - Cabletalk Group Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.

http://sourceforge.net/projects/phpdbedittk/

[John Dunlop]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Tony Marston wrote:
[color=blue]
> The cache is where the complete contents of the page is stored so that the
> next time the same page is requested it is retrieved from the cache instead
> of downloaded from the server.[/color]

Possibly.
[color=blue]
> I did not supply complete details about the caching mechainsim as it is not
> germaine to the issue under discussion.[/color]

Well, parts of it are, as RFC2616 explains.
[color=blue]
> The article is about using the browser's BACK button which is about moving
> backwards through the browser's history.[/color]

Yes. Something you cannot and should not influence.
[color=blue]
> If you visit a page that exists in your browser's cache then your browser
> will attempt to serve it from cache instead of re-issuing the request to the
> server.[/color]

Possibly. That depends on how you access it, the state of the
entity, configuration of your browser and any intermittent cache
proxy servers.

--
Jock

[John Dunlop]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

John Dunlop wrote:
[color=blue]
> Possibly. That depends on how you access it, the state of the
> entity, configuration of your browser and any intermittent cache
> proxy servers.[/color]

That should read "...any intervening cache proxy servers". Sorry.
Must remember to proof read articles *before* sending. :-)

--
Jock

[John Dunlop]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Jochen Daum wrote:
[color=blue]
> If you use IE and write down what you experience I beleive you would
> have such a document.[/color]

The folks responsible for that silly "browser" have openly documented
their ignorance of the internet standards. I'm not going to try to
understand what goes on in that piece of software specifically.

--
Jock

[Jochen Daum]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

Hi John!
On Wed, 18 Feb 2004 08:56:02 -0000, John Dunlop
<john+usenet@jo hndunlop.info> wrote:
[color=blue]
>Jochen Daum wrote:
>[color=green]
>> If you use IE and write down what you experience I beleive you would
>> have such a document.[/color]
>
>The folks responsible for that silly "browser" have openly documented
>their ignorance of the internet standards. I'm not going to try to
>understand what goes on in that piece of software specifically.[/color]

The point I try to make: You don't get around it, so you can construct
solutions, that serve all browsers and IE as well. IMO you don't need
to give up standards to serve it.

BTW.: I don't like the methods of MS, but I was impressed by an
article in a german linux Computer magazine in 2001. They tested 7
linux browsers and IE. IE 5 (I believe) rendered the pages fastest of
the tested browsers - in a Virtual machine.

So, I especially like it when open source browsers seem to copy all
the stuff that runs well in IE, without loosing all the ideas of the
Linux world. My favourite: Konqueror (3 upwards)


HTH, Jochen

[Tony Marston]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button


"John Dunlop" <john+usenet@jo hndunlop.info> wrote in message
news:MPG.1a9d25 545a955dbf98969 9@News.Individu al.NET...[color=blue]
> Tony Marston wrote:
>[color=green]
> > The cache is where the complete contents of the page is stored so that[/color][/color]
the[color=blue][color=green]
> > next time the same page is requested it is retrieved from the cache[/color][/color]
instead[color=blue][color=green]
> > of downloaded from the server.[/color]
>
> Possibly.[/color]

Not possibly, definitely.
[color=blue][color=green]
> > I did not supply complete details about the caching mechainsim as it is[/color][/color]
not[color=blue][color=green]
> > germaine to the issue under discussion.[/color]
>
> Well, parts of it are, as RFC2616 explains.[/color]

My article contains all the relevant information which is pertinent to the
topic in hand. Any other information is irrelevant.
[color=blue][color=green]
> > The article is about using the browser's BACK button which is about[/color][/color]
moving[color=blue][color=green]
> > backwards through the browser's history.[/color]
>
> Yes. Something you cannot and should not influence.[/color]

This is where I, and many others, have to disagree. The BACK button was
designed when the internet consisted of nothing more than static pages
without the ability to store any session data on the server. The ability to
produce dynamic pages and maintain server-side session data using languages
such as PHP has chamged all that. Where navigation between pages is now
controlled by links within the application the use of the browser's BACK
button can foul that up. As it is not possible to completely disable the
BACK button I have designed a mechanism which allows it to be used but
without any foul ups.
[color=blue][color=green]
> > If you visit a page that exists in your browser's cache then your[/color][/color]
browser[color=blue][color=green]
> > will attempt to serve it from cache instead of re-issuing the request to[/color][/color]
the[color=blue][color=green]
> > server.[/color]
>
> Possibly. That depends on how you access it, the state of the
> entity, configuration of your browser and any intermittent cache
> proxy servers.
>
> --
> Jock[/color]

I am not going to waste my time with explanations of irrelevant details. The
cache was designed to save the contents of visited pages in memory so that
when visited again they can be reloaded from memory instead of downloaded
from the server. It is either being used or it is not. It can either be
turned off by the user or turned off by the page author. The effect of proxy
servers with their own caching mechanism is irrelevant to this discussion.

--
Tony Marston

http://www.tonymarston.net

[Bruce Lewis]

Re: Raise your hand if you have ever wanted to disable the browser's BACK button

"Tony Marston" <tony@NOSPAM.de mon.co.uk> writes:
[color=blue]
> On some screens the number of hidden fields could be quite large, which
> means that the document will take longer to download as well as retransmit.
> Those of you who say that document size is not a problem are being totally
> inconsiderate to those users who do not have a broadband connection.[/color]

If a user is on a 56k modem, at least 4 kilobytes of data is needed to
add a second to upload/download time. For the vast majority of pages,
the possible time saved is not worth the loss of the back button.

As for being considerate of users' time, think about the much larger
amount of lost time if you're interrupted, say, by a child crying, and
return to your computer to find that the server has forgotten what you
were doing. Hidden variables have no timeout.

Speaking of interruptions, suppose you're using a helpdesk application
and are writing up the details on one trouble ticket. A call comes in
about another ticket, so you open a new window and start working on that
ticket. With hidden fields, each window has its own state. With
session data per-window state is much harder to do.

Finally, I would point out that those of you who recommend disabling the
browser's cache are being totally inconsiderate to those who do not have
a low-latency broadband connection to every web server they're
interested in.
[color=blue]
> Some of this data may also have security implications, so it is not a good
> idea to send it across the net within the body of the HTML document as it
> can be seen by anyone, especially by someone with nefarious intent. It is
> better to keep such data on the server.[/color]

If you aren't competent to securely handle the content of hidden
variables, then you can't securely handle the content of non-hidden
variables either. Just stay out of forms processing entirely.

Here's what should be stored in session state:
* user identity
* anything unvarying in this user session, e.g. time zone
* large and complex data structures unwieldy to put in hidden
fields

Everything else related to the user's state should go client-side.