83684 - Problems with session history on site with redirects and frameset

Status: RESOLVED INVALID

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

Description

[[e-mail]]

Used builds 2001053121/linux and 2001053120/WinNT:
When opening a frameset web site (http://www.derstandard.at), clicking a link 
in the center frame that changes that center frame the back button will not
work properly: it is not greyed out, but pressing it wont change 
anything. This can be repeated a few times or forever.
Sometimes, after a few times the browser will show
an ancestor of the previous page, but never the previous page.
This occurs extremely rarely with windows/2001053120 but on
linux/build2001053121 nearly everytime.
There might be some relation to the use of the 
<LAYER> tag in oneof the frames of the frameset?

To reproduce the bug:
goto http://www.derstandard.at and wait till the page is fully loaded.
the center part of the scrollable frame will suddenly look blank.
Scroll down within that frame until the first text in the center
part becomes visible. Click on the first link to the right of 
little triangle that points to the right. 
Click the back button.

Comment 1

[Ronald van Kuijk]

Confirmed on Linux build #2001060108

To me it seems it just skips the 'previous' page. Maybe because there seems to
be a redirect from http://derstandaard.at/standaard.asp?channel=...... to
http://derstandard.at/?channel=....

Comment 2

[[e-mail]]

Just tested with Linux build 2001060708 and still doesnt work.
This is a regression from (much?) earlier releases. Back button 
works with NS4.x when it doesnt with Mozilla.
I doubt that this is due to the page not following standards,
but maybe that plays a role.
Reproduce:
  1) http://derstandard.at/
  2) Click on "Politik" in the nav bar at top (or any other in the nav bar)
  3) try to get back

Comment 3

[James Ross]

I can confim this on Mozilla 0.9.1 (build 2001060810) running on RedHat 7.1.

It does seems to behave slightly differently, however - if you start on a
frameset page, and click a link, the back button doesn't even enable! Also, the
context menu 'Back' is still disabled.

I'm not into looking at the source for Mozilla, but it seems like it doesn't
think it's changed page, possibly because the URL at the top hasn't changed?

Comment 4

[Tom Mraz]

Behavior of session history on this page is completely broken. But testcase is
surely needed to actually debug it.

Comment 5

[Peter Evertz]

I have a simple frameset that shows the error of a not working back button.
Just put the zip on a webpage. Click to the nice lady. Try to go back.
Back button is not grayed, but does nothing.

I am new to bugzilla. So I don't know if I can upload the Zip.

BTW.: Using 0.9.1 Build ID 2001060703 for Windoof.

Comment 6

[Peter Evertz]

Attachment: A simple Frameset to show Back-button error

Comment 7

[Peter Evertz]

Sorry! 
Frame.zip does not always show the error. I will try to figure out what you must 
do to see the error. I think you have to have some special corrupted history. 
So may be the error (corrupting the hostory) is produced earlier and the error
is shown on a frameset like the one I have proivided.

Comment 8

[James Ross]

I've had this problem some times after just using a frameset page for a cartain
time. It works fine, until a certain time, when the back just stops working.
However, if I select the back list and try to go back *two* pages, it works.
Then it starts working again.

Build 0.9.1, on Linux.

Comment 9

[Tom Mraz]

Using Linux 2001062721.
There are at least two Mozilla bugs with this frameset.

Bug 11. Open the attached frameset in a new window
2. Click on the ZURUCK link
3. Try to browse and see that there is no history anymore - the back button
doesn't get enabled anymore.

This is caused by the history.go(-1) call which sets the history behind its
beginning.

Bug 2
1. Open the attached frameset in a new window
2. Click the photos_left.html link
3. Click the START link twice
4. Back button is enabled but doesn't work

This bug mutates when I use patched mozilla with the patch from bug 86330
It breaks already when you click the START link once!

I think the bug 1 should be logged as new bug but the Bug 2 is probably the same
as on the derstandard.at.

Comment 10

[Tom Mraz]

Actually the bug 1 is already reported as bug 84527.
The bug 2 is easily triggered on any framed page:

1. Load some framed page in new window
   for example: http://www.kaply.com/work/main.html
2. Press enter on the URL bar of the window to load the framed page again.
3. Back button is still greyed/disabled (it's OK, why not?)
3. Repeat step 2 
4. Back button is now enabled but it doesn't work and the history is corrupted.

It's very similar to the bug 68847.

Comment 11

[Keyser Sose]

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

Comment 12

[Radha on family leave (not reading bugmail)]

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

Comment 13

[Radha on family leave (not reading bugmail)]

Attachment: patch to docshell

Comment 14

[Radha on family leave (not reading bugmail)]

The attached patch has fix for another bug too. The first segment that has a
mention to this bug # belongs to this bug. 

Comment 15

[rpotts (gone)]

r/sr=rpotts.

Comment 16

[Judson Valeski]

r=valeski

Comment 17

[Asa Dotzler [:asa]]

a=asa on behalf of [e-mail]

Comment 18

[Radha on family leave (not reading bugmail)]

Fix checked in to trunk.

Comment 19

[Tom Mraz]

It seems to me that it is only partially fixed. The problems in the comment from
2001-07-10 00:49 are fixed. But the originally reported problems with the
frameset website derstandard.at aren't fixed. The history isn't corrupted but it
never returns to the previous page (only one of the frames changes after
clicking the back button).

Comment 20

[Tom Mraz]

Huh somehow the summary automagically changed?? Trying to restore the original.

Comment 21

[Claudius Gayle]

VERIFIED Fixed with 2001091203 build using every testcas I saw in this bug

Comment 22

[Natasa]

This bug does not seem to be fixed.  

If you go to to comment #2 and follow the steps as explained there or these 
here, you will see that the problem is not fixed:

  0) Go to "www.google.com
  1) Go to http://derstandard.at/
  2) Click on "Politik" in the nav bar at top (or any other in the nav bar)
  3) try to get back
->> You will be taken back to "www.google.com" instead of the derstandard.at's 
home page.

->> Note: tested with Netscape 6.2.3
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 

Comment 23

[Radha on family leave (not reading bugmail)]

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

Comment 24

[Radha on family leave (not reading bugmail)]

I looked into what's going on at www.derstandard.at.  When I go to the site, the
throbber never stops. There is something in the site that makes the network
layer believe that there is more data coming. This keeps session history and its
internal flags in limbo expecting more subframes to be added to the existing
frame structure. When I  click on the "Politik" link, since the previous load
was not completed, session history believes that this new page load is part of
the previous one and just adds the new frame navigation to the existing
hierarchy instead of creating a new  entry.  I think fixing the continous
throbber problem will automatically fix this bug.  I do not know what is making
the throbber keep going. There is no sign of any document. write() , which could
make the throbber keep going (if used without a accompanying document.close()).