39938 - After a redirect, the back button returns to the wrong page (the original page rather than the redirect target)

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P1)

Description

[David Muir Sharnoff]

After a redirect, the back button returns to the wrong page.  It returns to
the original page rather than the page that it was redirected to.

This is different than Netscape 4.* and IE.

In the example, Bepress uses cookies to authenticate.  If you visit a
page without having the right cookie, then you are redirected to a login
page.

After entering your password at the login page, you are redirected back
to your original page.  For unknown reasons, this sometimes takes multiple
redirects.  Netscape 4.* has a bug with this that the URL displayed in
the nav bar is wrong.  Mozilla is worse.

With Mozialla, after logingging in the nav bar is wrong but also
if you then go somewhere else and then hit the back button you return
to the wrong page.

Detailed example:

step 1: myaccount.cgi redirects to login.cgi 'cause you haven't logged in.
step 2: login.cgi redirects back to myaccount.cgi but the displayed URL
	 is wrong.
step 3: you click on Edit Profile (accountinfo.cgi).
step 4: you click back and end up at login.cgi rather than myaccount.cgi.

Easiest thing to do is just try the page with the different browsers to see
what I mean.

PS.  I'm the programmer for Bepress.

Comment 1

[Jesse Ruderman]

This looks similar to bug 24143, but I'm not sure if they're the same.

Comment 2

[don]

Move to M20 target milestone.

Comment 3

[Radha on family leave (not reading bugmail)]

*** Bug 45542 has been marked as a duplicate of this bug. ***

Comment 4

[Claudius Gayle]

Radha, this does look like bug 24143 (which is itself related to bug 10647). We should close one of these(this or 24143) out.

Comment 5

[Claudius Gayle]

*** Bug 45717 has been marked as a duplicate of this bug. ***

Comment 6

[Radha on family leave (not reading bugmail)]

*** Bug 24143 has been marked as a duplicate of this bug. ***

Comment 7

[Radha on family leave (not reading bugmail)]

nominate for beta3. Redirection is a big hole right now. 

Comment 8

[johng]

nav triage team:
nsbeta3+

Comment 9

[Bill Law]

and P1.

Comment 10

[Phil Peterson]

PDT thinks this is a P3. Changing priority and leaving [PDTP3] in status whiteboard

Comment 11

[Radha on family leave (not reading bugmail)]

nsIHttpSink is passing on wrong loadTypes to docshell. I think taking care of 
this problem will knock off a bunch of  bugs on my list regarding redirections.. 
Making P2. Gagan, Ruslan I need some info from you. When necko detects a 
redirection for the main url that it is trying to load(not gif, png redirects 
etc..) where does it send a notification? nsDocLoader::OnRedirect(seems to get 
redirection notices on all types of redirections including images etc... How can 
we differentiate a url direction from everything else?

Thanks,

Comment 12

[johng]

nav triage team:
P2
Will bring to pdt if Radha can't get help...

Comment 13

[selmer (gone)]

Please come state your case, marking P3.

Comment 14

[Gagan]

For the record-- I missed this question amongst the several bugs that I have to 
deal with. Next time ifyou have a question, send me an email-- lets leave 
Bugzilla for the bugs tool that it is. 

Necko uses nsIHTTPEventSink on which it fires the redirect messages. We inside 
necko have no way of telling if a channel is the main page or an embedded image. 
The best way for you to handle this is to see if this channel is the default 
channel for this load group. In which case it would reflect the page instead of 
individual images. mscott did the implementation for the nsIHTTPEventSink so you 
might get more help from him. 

Comment 15

[Radha on family leave (not reading bugmail)]

Reporter, can you try this again. I don't see a major goofup. The behavior seems 
to pretty much like Nav 4.7. Thanks,

Comment 16

[don]

Chaning to minus.  Do we have a real problem here?  Should this be an RTM candidate?

Comment 17

[Radha on family leave (not reading bugmail)]

There seems to be some problem. It is not clear what the expected behavior is. 
Nominating for beta3

Comment 18

[johng]

nav triage team:
every link to netscape.com from the client uses a certain kind of server side
redirect.  Back button for 4.x does work in these cases, but seamonkey does not.
 This is critical not only for netscape, but many other portals do the same
thing.  Need to fix so back works on portals.

RTM NEED INFO, P2 so that when we get a patch, we can rtm+ this.

Behavior to better explain problem:

> User is on page A
> User clicks link (perhaps a link in the Task Bar under Business or Fun).
> User goes to page C (redirect link goes to URL B which, invisible to user,
forwards the browser to page C)
> User hits back button, but that just reloads page C, doesn't work (actually
does goes back to URL B which again redirects the user back to page C).

Comment 19

[Gagan]

this problem in a little similar way gets aggravated on frames. (see a possible
dup at bug 46828)

Comment 20

[Radha on family leave (not reading bugmail)]

Actually, we seem to do fine on server side redirects. Clicking on link on 
Business/Tech Tab on the task bar does do a server side redirect. But we detect 
these redirections before the original page(the page that redirects) gets added 
to SH. So, we  add only the redirected page (In JohnG's  example it will be page 
C) in to Session History. So, if you click back, you go to where you were before 
getting to page C. We do not go to the in-between page that did the redirection.

It is the client side redirections that cause the problem. Client side 
redirections include pages that have a location.href="Redirected page" in the 
Javascript onLoadHandler() or pages that have timers that trigger a redirection 
once you visit them. 

An example of former is netscape home page. home.netscape.com has a 
location.href that redirects you to home.netscape.com/index1.html?cp=hom10pr2. 
This gets recorded as 2 entries. So if you click back, you go to 
home.netscape.com which again redirects you to 
home.netscape.com/index1.html?cp=hom10pr2.

An example of timer redirects is in bug # 54898(a dependant of this bug). In 
Nav4.x you can see the interim page that has the timer for a fraction of a 
second and then it gets redirected to 
http://msdn.microsoft.com/library/default.asp?URL=/library/books/winguide/ch00a.
htm. In Mozilla, you can not see that intermediate page. Here also, pressing 
back, takes you to the interim page which redirects you to where you were. 

I tried out links off of yahoo & netcenter. I saw the getting redirected and 
Session History was doing OK on them. 

Comment 21

[don]

Radha, have you tried links off of http://www.cnet.com/ ?  These seem to be
swallowed as well when going back.

Comment 22

[don]

OK, making this rtm- because, after Radha's email and talking to Claudius and
John Gable, we believe this only affects client-side re-directs.

Comment 23

[Viswanath Ramachandran]

nav triage team: beta stopper. P1. 

Comment 24

[Paul Chen]

nav triage team:

Marking nsbeta1+

Comment 25

[Radha on family leave (not reading bugmail)]

Attachment: Patch for META refresh based redirects

Comment 26

[Radha on family leave (not reading bugmail)]

Attached a patch that addresses one type of clientside redirection: META refresh 
based ones. Patch for JS based ones yet to come...

Comment 27

[Radha on family leave (not reading bugmail)]

*** Bug 64979 has been marked as a duplicate of this bug. ***

Comment 28

[Radha on family leave (not reading bugmail)]

*** Bug 54898 has been marked as a duplicate of this bug. ***

Comment 29

[Radha on family leave (not reading bugmail)]

*** Bug 53573 has been marked as a duplicate of this bug. ***

Comment 30

[Radha on family leave (not reading bugmail)]

Attachment: Diffs that take care of JS redirects too

Comment 31

[Judson Valeski]

what happens in the HTTP redirect case?

Comment 32

[Radha on family leave (not reading bugmail)]

HTTP refresh response headers follow the same code path as META HTTP-EQUIV
refreshes. so this patch will affect HTTP refresh response headers.

Server side redirects work well as  it is and this patch does not affect server
side redirects.

Comment 33

[rpotts (gone)]

hey radha,

The changes look good to me... (r=rpotts)

Comment 34

[Radha on family leave (not reading bugmail)]

Fix checked in few minutes ago.

Comment 35

[Adam Lock]

Too late now I guess, but here is the comment from my email:

"It looks ok to me too, as long as you're happy that the busy flag in the 
docshell could mean either the docshell or one of its children is busy. "

Comment 36

[Tom Mraz]

Can someone (original reporter) mark it as verified? It should be fixed for a
long time and I cannot see anything strange at http://www.cnet.com/, but I can't
test the original URL.

Comment 37

[David Muir Sharnoff]

The original URL should still work as advertised.  You must
sign up for a bepress.com account first (free).

Comment 38

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]