182689 - Back button does not work (nested frames)

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Cristian Seres]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

Back button and Alt+left arrow shortcut stop working if you browse at given URL
and go back and forth between the pages.

Reproducible: Always

Steps to Reproduce:
1. Click 'Palvelut' link on the left upper corner.
2. Click 'Arpikorjaus' or any other link in the middle of the page.
3. Click 'Palvelut' link again to get back to previous screen. Note: If you use
Back button instead, the bug does not occur.
4. Click 'Arpikorjaus' or any other link in the middle of the page. Note: Does
not need to be the same link than in step 2.
5. Click Back button or backspace to get back to the previous page.

Actual Results:  
Nothing happens.

Expected Results:  
'Palvelut' page should have been opened, because it was previously visited page.

Comment 1

[Daniel Wang]

chg url

simplified steps to reproduce:
1. go to http://www.siluetti.net/html/center.htm
2. click on Palvelut
3. click on Arpikorjaus (or any link in the loaded frame)
4. click on Palvelut
5. click on back button

result: jump back two steps to Palvelut (in step one)

expected: jump back to Arpikorjaus

I'll be preparing a reduced testcase for this bug.

Comment 2

[Daniel Wang]

Attachment: testcase

It seems that if you have a frameset page, and a link loads another
frameset page in a frame, and the nested frameset is updated. Then if
you load the nested frameset again by following the same link, the
session history gets funky.

Comment 3

[Daniel Wang]

test procedure:
1. follow
jar:http://bugzilla.mozilla.org/attachment.cgi?id=108534&action=view!/index.html
2. click on "one"
3. click on "sample link"
4. click on "one"
5. click back

Comment 4

[Ian Nartowicz]

I think this is a duplicate of 171165.  The behaviour looks more complicated,
but the frames explanation as given by dwx is the same problem as the other bug.

Comment 5

[Andrew Schultz]

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

Comment 6

[Andrew Schultz]

from bug 207303: there is a simple testcase at
http://www.student.oulu.fi/~tomilepp/koe/
click [frame2], [frame2-b], [frame2], [frame2-b]: back button stops working.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Not blocking1.5alpha, but a serious bug that's definitely worth fixing.

Comment 8

[Dustin Mitchell]

This also seems to occur after some time using Zope management screens, which
produce page after page titled "Zope on http://foo.com" for foo.com your domain
name.  I'm not sure exactly how many clicks it takes, but pretty soon clicking
"Back" does nothing.  I'd be glad to test more specific circumstances, if suggested.

Comment 9

[Ben Cohen]

Using the http://www.student.oulu.fi/~tomilepp/koe/ example, you can reproduce
the bug with only 3 steps:  click [frame2-b], [frame2], [frame2-b].  

This seems to occur because when you click [frame2] you are replacing
"frame2.html" with the identical URI "frame2.html", but the frame children are
not the same:  "frame2-b.html" is replaced with "about:blank".  

Since the "frame2.html" URIs are the same, nsDocShell::OnNewURI() sets
"mLoadType = LOAD_NORMAL_REPLACE".  This seems to make
nsDocShell::AddToSessionHistory() behave incorrectly, and the children don't
get updated properly.

(Then when you click [frame2-b], Mozilla can't make the replacement in the
session history because of the earlier problem; instead it just makes a copy.
So when you press the back button, Mozilla tries to find the difference
between the two entries in the session history, and there is none so it can't
handle the request.)


I found that a workaround is simply to remove the if statement with the line
"mLoadType = LOAD_NORMAL_REPLACE" from nsDocShell::OnNewURI().  This has other
effects - creating new session history entries when a page with the same URI
is loaded - but it does appear to fix this bug.  (Note also the reference to
bug 83684.)

Comment 10

[Frank Fahs]

I've been experiencing this issue primarily trying to access phpmyadmin.  I have
tested it using MAC OS X 1.5b and 1.5rc2, windows XP 1.5b and several different
phpmyadmin setups (versions 2.4.x to 2.5.x) on different IP addresses or URLs. 
This is the quickest way to get to the issue I am always getting...

--Access a database using the pull down in the left (NAV) frame.
--Access a table using the links in the left frame
--Click SQL tab in right (CONTENT) frame
--In the right frame, Click the submit button labeled "GO" to get a quick view
of all data (SQL statement should already be in textarea)
[Now in the resulting window you can at this point hit the back butto to get
back to the SQL query window and edit your Query, but...]
--In the right frame click just about any link but the SQL tab works for this
example
--Click the browsers back button, click OK to resend the POST data
--Now try to click the Back button (which is highlited as on and has accesible
history) again to get back to the window which sent the post data, ****nothing
happens****
[This also happens on the Forward button by reversing some of the steps above]
--Click links such as to other tables in the right frame and then try to hit
back button and it still does not work, essentially it is now disabled

---IF you use the back button history drop down and access the link just before
the problem page (may be several links back if you have clicked around) which is
somehow the original SQL query, This will work and reactivate the Back button.

This also happens in Firebird (0.6.1)

For those asking how the heck did i discover this (frmae of mind sometimes is a
big help trying to understand directions, no?) I am learning and testing SQL
statemtents and am repeated going 'Back' to correct mistakes or make
adjustments. Eventually i went forward once and then tried to go back and began
to get this issue.  In my work I am actually hitting it often.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So the issue here (the original issue; I have no idea whether comment 10 is the
same thing) is that docshell has code to turn a load for the same URL into a
"replace" load.  This is fine if none of the frameset in question have had any
pageloads since the initial frameset load.  If they have, the load shouldn't
turn into a "replace" load.

See nsDocShell::OnNewURI.

The original URI equality check was added to fix bug 49913

Comment 12

[Boris Zbarsky [:bzbarsky]]

Note: Just storing a flag on the sh entry to indicate that some descendants were
modified (and skipping the URI equality check if they were, as in this bug) is
not enough, since CloneAndReplace doesn't replace the mOSHE's of the docshells
with the cloned entries.

I'm coming to think that CloneAndReplace should be replaced with something less
hacky, somehow.

Comment 13

[Boris Zbarsky [:bzbarsky]]

To reproduce this _very_ easily, by the way:

1)  Load data:text/html,<frameset><frame src="http://mozilla.org"></frameset>
2)  Click any link in the frame to load a different page in the frame.
3)  Focus the URL bar and hit enter.
4)  Try to go back.

Comment 14

[clubic.com]

Nothing new with this bug. The problem is style here and reproductible.
Something strange, with firefox 0.8, the problem seems to had disapeared but
with new version (and even whith firefox 1.0 rc1), the problem came back.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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

Comment 16

[:Gavin Sharp [email: [e-mail]]]

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

Comment 17

[Wayne Mery (:wsmwk)]

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

Comment 18

[Hallvord R. M. Steen [:hallvors]]

Still an issue per the test case in comment 13