[WSG] Cannot go back

[Simon Cockayne]

Hi,

I use an internal web application that someone else coded.

Once I have navigated to URL for this web app (from whenever I was) I can
never go back to where I came from...which is very frustrating.

The developers of the web app say that the back button processing has been
overridden and it is not possible to go back to the place the user was
before they entered the web app.


Is there no standard way to prevent the back button from really going
back...but provide some mechanism (a different button/link on the page) to
allow the user to go back to where they were before the app started?


Oh..and Happy New Year.

Cheers,

Simon


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cannot go back

[Jamie Stewart]

There are a couple of ways of putting links on your page which mimic the
back button that I know of.

One is by using JavaScript, history.back() is what you will want to use.  If
you don't want to use JavaScript it is possible through code, well with .Net
at least.  You can easily access the UrlRefferer which gives you the full
URL of the previous page.

I hope this helps

Jamie.


On 17/01/2008, Simon Cockayne [EMAIL PROTECTED] wrote:

 Hi,

 I use an internal web application that someone else coded.

 Once I have navigated to URL for this web app (from whenever I was) I can
 never go back to where I came from...which is very frustrating.

 The developers of the web app say that the back button processing has been
 overridden and it is not possible to go back to the place the user was
 before they entered the web app.


 Is there no standard way to prevent the back button from really going
 back...but provide some mechanism (a different button/link on the page) to
 allow the user to go back to where they were before the app started?


 Oh..and Happy New Year.

 Cheers,

 Simon

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cannot go back

[Andrew Maben]

On Jan 17, 2008, at 5:11 AM, Jamie Stewart wrote:

One is by using JavaScript, history.back() is what you will want to  
use.  If you don't want to use JavaScript it is possible through  
code, well with .Net at least.  You can easily access the  
UrlRefferer which gives you the full URL of the previous page.


Of course, disabling the browser back button is evil and  
unnecessary...


The JS solution might work, but the question is how far back in the  
history one must go to escape the clutches of the evil app.


In my day job, the library's web site offers patrons access to  
various subscription databases - the user authenticates with a valid  
library card number on our site and is then passed forward to the  
database site. (Oh yes, and the back button does work). Almost daily  
we get complaints from patrons that the authentication doesn't work  
for them. In almost every instance we find they have Norton Internet  
Security installed. By default Norton suppresses referring URLs. This  
is a hugely popular app that most users install and never even look  
at the settings.


So neither of these solutions will be 100% reliable.

I'm probably a bit of an extremist, but I'm probably not alone - if I  
visit a site that tries to keep me imprisoned like this, I close the  
browser window and *never* return. No site is so compelling and so  
unique as to require that I (or any other user) put up with this abuse.


Can you ask the developers why and how they created this  
dysfunctionality? My guess is that there's some kind of preprocessing  
that goes on before allowing the user into the site itself, and the  
back button takes the user back to that page, which bumps them  
forward again. There is no technical constraint that requires this  
behavior. I seem to recall some wisdom from the 90s that proclaimed  
the desirability of keeping users on your site at all costs, but that  
has long since been discounted. But if there really is some  
compelling non-technical reason for not allowing users to escape back  
the way they came, then I'd suggest that this is a case where opening  
a new window would be justifiable.


Andrew







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***