44660 - Loading pages from What's Related sidebar breaks back button

Status: VERIFIED DUPLICATE of bug 32444

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

Description

[Asa Dotzler [:asa]]

tested on Mozilla build 070608 Mac OS 9

steps to repro:
1. load any webpage
2. load any other webpage
3. load Smoketest page from the browser QA menu or load a what's related page.
4. hit the back button.

results: can't go back.
expected results: should be able to go back.
additional info: the page loaded before the smoketest page disappears from the
back button popup history.  also, you can still navigate back but using the back
button popup history (except for the missing previous site).

Blake also saw this on a win32 mozilla build from today using WinME(98)
not sure about linux yet.

Comment 1

[Claudius Gayle]

wow, freaky bug. I reproduced this on Linux with the 2000071008 build. I used the QA menu link to the smoketest page. That 
pages replaces your previous SH entry with itself in the popup lists. Back button is enabled but inoperative. The same thing 
happens if you are at the page before(in SH) the offending page and try to go forward to it.

Comment 2

[Asa Dotzler [:asa]]

is this the same as bug 42178?

Comment 3

[Asa Dotzler [:asa]]

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

Comment 4

[Lynn Webb]

Just wanted to add that if you click on a sidebar link, you are taken to that 
URL, but then if you click on the browser's BACK button, you can't go back to 
the last page viewed. The BACK button works fine with pages in the main browser 
window, but not with sidebar pages.

Comment 5

[Blake Ross]

Items in the QA menu use window._content.location.href to navigate to their 
respective sites, making this a dup of 46499, which is in turn a dup of 41438 
(see the rationale at 46499 for why).

The What's Related panel is a bit different.  It uses appCore.loadUrl with a 
fallback on ContentWindow.location (which might make it a dup of 42723) if 
appCore isn't available.  In fact, a comment even notes: // support session 
history (if appCore is available).  Thus, the fallback case doesn't work well 
with SH.  However, I'd assume that appCore is available most of the time, so it 
probably isn't hitting the fallback case (so this probably isn't what's causing 
the problem).  So, loadUrl is really the nsBrowserInstance::LoadUrl member 
function, exposed through the nsIBrowserInstance IDL.  It in turn calls 
nsDocShell::LoadURI 
(http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#214), 
which has a bunch of SH-related comments.  This one: "// XXX: Should we care if 
this QI fails?" makes me wonder, since it's referring to the failure to 
retrieve the SHentry from the parent.  In any case, I think this is a separate 
bug than all the other "back doesn't work" bugs, so I'll going to leave it open 
for radha to investigate.

Making this bug just the What's Related part now, since the QA menu aspect of 
it is a dup.

Comment 6

[Blake Ross]

Hmmm...one of the comments in the LoadURI() function reads:

"     /* Check if we are in the middle of loading a subframe whose parent
      * was originally loaded thro' Session History. ie., you were in a frameset
      * page, went somewhere else and clicked 'back'. The loading of the root 
      * page is done and we are currently loading one of its children or sub-
      * children.
      */
"

This sounds exactly like the situation that is broken in bug 32444 (the 
frameset issue).  It's a long shot, but I'm gonna very tentatively mark this a 
dup of 32444.  Radha, could you either verify, or reopen this and make me look 
like a fool (the likely course of action :-) ?

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

Comment 7

[Blake Ross]

To clarify the dup a bit more, the links in the What's Related panel are (after 
being passed from function to function) eventually loaded via LoadURI().  Since 
the code to handle SH frameset issues like bug 32444 also seems to be in LoadURI
(), I'm thinking these could be dups...

Comment 8

[sairuh (rarely reading bugmail)]

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

set your search string in mail to "CitizenGKar" to filter out these messages.