28142 - Back button loads page in wrong frame

Status: VERIFIED DUPLICATE of bug 36547

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Damian Christey]

Using linux build 2000-2-16-16 on Redhat 6.1. 
Steps to reproduce:
1.  Go to http://www.crosswinds.net/~precision
2. Click on a link in the top frame such as "gallery"
3. Click on another link in the top frame such as "location"
4. Click the back button
Result: The gallery page is displayed in the top frame, the locations page
remains in the bottom frame.
Expected result: The bottom frame should change to the previous page "gallery" ,
and the top frame should stay the same.

Comment 1

[karnaze (gone)]

Reassigning to Radha.

Comment 2

[Joseph Elwell]

same for me on winNT build 2000021708.

Comment 3

[Joseph Elwell]

This is because of the use of target to update frames other than itself.

Comment 4

[Damian Christey]

Attachment: Test Case

Comment 5

[Damian Christey]

Attachment: don't go to this one

Comment 6

[Damian Christey]

Attachment: don't go to this one

Comment 7

[Damian Christey]

Attachment: don't go to this one

Comment 8

[Damian Christey]

Attachment: don't go to this one

Comment 9

[Damian Christey]

sorry about that :-( someone suggested i send a test case. should have known
better. 

Comment 10

[Damian Christey]

Terribly sorry for the spam. For the simplified test case, go to
http://web.mountain.net/~damian/frame_test/index.html

Comment 11

[Joseph Elwell]

This is affecting Yahoo mail. bleagh. I didn't think it was that bad but it is.

:( That's a top100 right?

Comment 12

[Michael La Guardia]

This seems like a bad bug, but given that Radha is not here and there is no
indication of when this will be completed or whether there is a fix in hand,
removing PDT+ for reconsideration.

Comment 13

[Joseph Elwell]

I notice that a lot of my PDT+ bugs vanish right before a Milestone release -
and they don't gett fixed. They're are marked duplicate, invalid, or worksforme
often the PDT+ is just erased from the Status board. This is the 3rd bug today
that it's happened on with the M14 build right around the corner. What I'm
really asking is wiping PDT status policy?

Comment 14

[Damian Christey]

I beg you to reconsider.  This may not be that serious or even dificult to fix,
but it's going to show itself every time someone clicks the back button on a
frames site. Anyone want to guess how often that will happen? This is not going
to make a good impression.

Comment 15

[Eric Pollmann]

I'll take this since Radha isn't around, hope I can help!

Comment 16

[Eric Pollmann]

In this case, when we go to nsSessionHistory::Add(), we pass in the webshell
that the link was clicked on as the "this webshell" pointer.  When going back in
history, we update the "this webshell" with the URL.

Since we clicked on the link in the top frame, it gets added as "this webshell"
even though the link is actually loaded in the bottom frame.  When going back in
history we update the URL of the top frame.

I think the solution is to just find the webshell that the new document is going
to be loaded in before calling nsSessionHistory::Add.  I'm still in the
assesment phase of this bug, but don't think it will be that nasty of a fix
(famous last words).  :)

Comment 17

[leger]

Putting on PDT+ radar for beta1.  But will move to PDT- if not fixed by 03/03 or 
regression occurs.

Comment 18

[Eric Pollmann]

I fixed that problem in my tree.  It turns out webshell has a parallel problem. 
After a URL loads, it sets mURL to be that URL.  Even if the URL didn't load in
this webshell.

So in this example, clicking on the 'click here' link sets mURL of the webshell
for the top frame to page2.html when in reality it should set mURL of the
webshell for the bottom frame to page2.html.  This causes problems when session
history compares the two urls, deciding which webshells to reload.  I'm still in
the assesment phase of this bugfix, but it's looking at least slightly bigger
than the one line fix I had hoped for.

Comment 19

[Eric Pollmann]

Fixed the webshell problem and this bug was fixed.  :)  I have much testing to
do on this change.

Comment 20

[Eric Pollmann]

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

Comment 21

[Eric Pollmann]

The routines I have to change are going to be completely scrapped in the ongoing
webshell rewrite.  As such, and as recommended by the webshell module owner, I'm
not going to continue with this fix for beta1.

Passing back to Radha (I don't think this will get done by 3/3)

Comment 22

[Eric Pollmann]

Note bug 29750, a symptom of the webshell problem mentioned above, can be fixed
without fixing this bug, but if this bug is fixed properly for targetted pages,
that bug should be fixed too.  Please verify bug 29750 when verifying this bug. 
Thanks!

Comment 23

[don]

Removed PDT+ for re-consideration.  There's no way we're gonna fix this until
Travis lands all his new Webshell changes and enables Radha's new Session
History.

Comment 24

[Damian Christey]

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

Comment 25

[Damian Christey]

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

Comment 26

[Claudius Gayle]

the url for another good min. testcase http://members.home.com/jfranklin1/tests/frame.html (from bug 29972)

Comment 27

[sentinel]

Sorry for the spam, just getting myself on the cc list ...

Comment 28

[Phil Peterson]

PDT-

Comment 29

[Eric Pollmann]

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

Comment 30

[Eric Pollmann]

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

Comment 31

[Eric Pollmann]

Please also verify Bug 28142 after this fix.  It is another symptom of this
problem (clicking reload sometimes loads the wrong document into a frame).

Comment 32

[Eric Pollmann]

Er, I meant to say: "Please also verify Bug 28971 after this fix."

Comment 33

[leger]

Adding relnote keyword.

Comment 34

[Claudius Gayle]

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

Comment 35

[Dwayne]

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

Comment 36

[Radha on family leave (not reading bugmail)]

Moving to M15...

Comment 37

[Radha on family leave (not reading bugmail)]

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

Comment 38

[Eric Pollmann]

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

Comment 39

[Eric Pollmann]

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

Comment 40

[Asa Dotzler [:asa]]

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

Comment 41

[Alan S. Jones]

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

Comment 42

[don]

Move to M16 for now ...

Comment 43

[Damian Christey]

Nominating for beta 2, hoping that the webshell changes make it in by then,
otherwise hoping that there is some other fix for this.

Comment 44

[sarnold]

Would this be a related error? Sometimes, while viewing a frames-enabled
webpage, using the back button twice will cause a user to exit the page
completely. I saw this with April 10th CVS build on Linux.

To see this for yourself, view http://www.willamette.edu/~sarnold/, click on the
"dave barry" link. Click on any of the articles archived, click back once. Click
on any of the articles, click back once.

I would expect to still be at the Miami Herald webpage, but instead one is
returned to the willamette.edu page.


I get the following ASSERTION errors; maybe this will help?

(If this is unrelated, please do let me know. Thanks. :)

###!!! ASSERTION: NS_ENSURE_TRUE(docShell) failed: 'docShell', file
nsGlobalWindow.cpp, line 4089
###!!! Break: at file nsGlobalWindow.cpp, line 4089
JavaScript error:
 line 0: uncaught exception: [Exception... " 0x80004005 (NS_ERROR_FAILURE)
[nsIController.isCommandEnabled]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "JS frame :: chrome://global/content/globalOverlay.js ::
goUpdateCommand :: line 202"  data: no]

###!!! ASSERTION: NS_ENSURE_TRUE(docShell) failed: 'docShell', file
nsGlobalWindow.cpp, line 4089
###!!! Break: at file nsGlobalWindow.cpp, line 4089
JavaScript error:
 line 0: uncaught exception: [Exception... " 0x80004005 (NS_ERROR_FAILURE)
[nsIController.isCommandEnabled]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "JS frame :: chrome://global/content/globalOverlay.js ::
goUpdateCommand :: line 202"  data: no]

->>>>>>>>>>>>>> Write Clipboard to memory
###!!! ASSERTION: NS_ENSURE_TRUE(docShell) failed: 'docShell', file
nsGlobalWindow.cpp, line 4089
###!!! Break: at file nsGlobalWindow.cpp, line 4089
JavaScript error:
 line 0: uncaught exception: [Exception... " 0x80004005 (NS_ERROR_FAILURE)
[nsIController.isCommandEnabled]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "JS frame :: chrome://global/content/globalOverlay.js ::
goUpdateCommand :: line 202"  data: no]

###!!! ASSERTION: NS_ENSURE_TRUE(docShell) failed: 'docShell', file
nsGlobalWindow.cpp, line 4089
###!!! Break: at file nsGlobalWindow.cpp, line 4089
JavaScript error:
 line 0: uncaught exception: [Exception... " 0x80004005 (NS_ERROR_FAILURE)
[nsIController.isCommandEnabled]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "JS frame :: chrome://global/content/globalOverlay.js ::
goUpdateCommand :: line 202"  data: no]

Comment 45

[leger]

Putting on beta2+ radar.

Comment 46

[Eric Pollmann]

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

Comment 47

[leger]

Updating [beta2+] in Status Summary to [nsbeta2+]

Comment 48

[Claudius Gayle]

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

Comment 49

[Damian Christey]

Ok, as sarnold pointed out, the behaviour I described in this bug is no longer
happening when viewing pages such as my test page with the latest builds
(2000-4-21-13).  Now the back button will take you to the last page you viewed
before the one containing the frameset.  Does this call for a new bug?

Comment 50

[Radha on family leave (not reading bugmail)]

There is already a bug for "no history in frameset pages" assigned to me.

Comment 51

[Linda Baliman]

Demian Turner, iii.co.uk, added to cc-list.  iii is Stocktrade's developer, and 
Stocktrade is affected by this bug.

Comment 52

[Andreas Franke (gone)]

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

Comment 53

[R.K.Aa.]

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

Comment 54

[Braden]

It looks like this bug has morphed to tracking the same thing as bug 36547. This
bug is older, but 36547 articulates the problem better.

*** This bug has been marked as a duplicate of 36547 ***

Comment 55

[Claudius Gayle]

this should've just been closed back on 4-21 but ok, verifying as a dupe

Comment 56

[Eric Pollmann]

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