From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011009 BuildID: 2001100908 From www.cnn.com, if you click on a link on that page (specifically, I clicked on a link in the right hand column -- doesn't matter which) and then click the back button on Mozilla's tool bar, it takes me back to my home page. Further, if I open a new browser (with ATL-N) and go to www.cnn.com I can't even access the back button -- it stays grayed out. Reproducible: Always Steps to Reproduce: 1. Go to www.cnn.com 2. Click a link. 3. Try to go back, if you can Actual Results: Sometimes it takes you back to your home page, when it should take you back to www.cnn.com Other times the back button just isn't available. Expected Results: It should work like a back button always has... taking you back just one page.

Ohhh yeah. I just saw the same thing on CNN.com. Build 2001100903, Win98, so it's probably platform->ALL. It's intermittent, though, and I've only seen the case where the back/forward buttons become unavailable.

i saw the back-button activate only once there, having clicked my way 6 pages in, and then it didn't work and the dropdown menu was an emtpy little sqare placed to the far left of the back-button.

Same problem with cnn.com on SPARC/SunOS 5.9, build 2001100921. Sometimes "back" has no drop-down menu at all, other times it's an empty tiny box.

Something else weird to add to this bug. If I turn off Javascript, I don't seem to be able to reproduce the problem. At least, so far. Can anyone else confirm this? If so, it would suggest the problem is maybe Javascript? In any case, based on comments, platform-->ALL

Based on other comments, and confirmation on my part, I am changing the Component from general to Javascript. It seems that this bug doesn't exist when Javascript is disabled.

that's not a valid reason to use that component, please read the descriptions http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

I see this problem on pages I visit after CNN using other methods (e.g., bookmarks) as well and it seems to affect all windows. I've also noticed that dropping down the Go menu can show the checkmark on the wrong page or not at all. As I recall, this didn't start happening after doing an upgrade to a new nightly, so it may not be a regression. It may simply be an existing bug exposed by changes on the site.

Is this a recent regression?

Radha, I thought this was a recent thing, since I only started seeing it around 08-Oct. But I just tried build 2001100103, and see the problem. So maybe it's something that changed on CNN's site recently, as opposed to a change in Mozilla itself. Certainly, I only see this problem on the CNN site.

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

I'm fairly sure I'm seeing the same thing here. It looks like loading an article basically removes the main http://cnn.com/ page from the history, so hitting back goes to the page I was on immediately before I loaded CNN. The back button dropdown shows the same thing (the first thing back it shows is the page I was on before I went to CNN). If I go back to that page, the forward button actually *does* take me back to the main CNN page, not the article. The forward button history dropdown on the previous page shows "CNN.com" (the main page) *twice* and then the article. After hitting forward and landing on CNN.com, the forward button dropdown is empty. It just shows a small box when selected. But the button is still active (not greyed out). But nothing happens when it's pushed. Weird.

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

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

The machine I saw this on this morning was linux with a 10-08-2001 nightly build. On the machine I'm at now, FreeBSD with the linux 2001101208 build, I can't reproduce it...

Steps to reproduce: 1) Load some pages 2) Load attachment 53293 [details] Expected result: can go back Actual result: back button enabled but non-functional. "back" dropdown menu comes up but is empty. Notes on testcase: 1) The <iframe> is necessary to get this result 2) The <style> is necessary to get this result 3) All the <script> tags are necessary 4) Putting the toolbar.netscape.com JS inside the <script> tag instead of having it be linked externally makes this bug disappear. It almost feels like something is stomping on memory somewhere.... I'm not seeing this bug on the testcase with current opt trunk from cvs, but I'm seeing it on cnn.com with the opt trunk and I'm seeing it on the testcase with a 0.9.5 branch build.

I'm not seeing it with the test case on this machine (the above mentioned FreeBSD machine with the linux 2001101208 build).

Is bug 99830 a dupe of this, or vice versa?

I don't see this on the trunk with debug or opt. I do see it on the 0.9.5 branch, though.

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

I've attached a patch that does fix the problem but may be the wrong way to fix it, I'm not sure. Anyway, here's what is happening. When cnn.com is loaded there are some frames that are created without content. When you do that, the frames are automatically loaded with about:blank. The first frame is created normally. However, when the second frame is created, |and nsDocShell::LoadURI| is called to load about:blank into the frame one of the things that it does is check the load type, and if it isn't a history replace ( LOAD_NORMAL_REPLACE ) call then it tries to reload itself as a history entry via |nsDocShell::LoadHistoryEntry|. When this happens mLoadType is set to LOAD_CMD_HISTORY and in |nsDocShell::OnNewURI| the index is updated on the root session history, blowing away all of the history. I'm not sure if checking explicitly for LOAD_HISTORY is the right fix since that might not be passed down when going back in frames. However, it does fix the reported bug. Can someone "in the know" look this over?

I will take a look at this shortly. There are quite a few conflicting reports on whether the bug is reproducible and in what platforms. If it is a recent regression, I would like to see what regressed this. The area of code in which blizzard is proposing the change has been around for a long time(> 1 year) Plus, I believe that change will break some subframe navigations. There has been recent changes in GetChildShEntry() that deals with expired documents and specifically subframes. One of my guesses is that, cnn may be creating subframes that are already expired or will expire shortly, since there is more dynamic content in their site nowadays.

I'm not seeing this specific problem anymore in 2001101212 on Linux. But I just ran into a possibly related problem. I was on http://us.imdb.com/Title?0090060, clicked to http://us.imdb.com/Name?Winningham,+Mare, and then went back. The forward button isn't greyed out, but the dropdown is empty (it shows a small box) and clicking forward doesn't do anything. Related?

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

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

Bug also appears reproducibly on a Mac.

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

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

Rhadha, look at the test case. The test case uses anonymous frames that load about:blank and cause the problem. Are there expiration issues there? It seems to be triggered by two frames that load the exact same content. In CNN's case there are two subframes that load the same content and this bug is triggered. Look at the names of the urls that are loaded in |nsDocShell::OnNewURI|.

Keeps getting weirder. I just experienced this problem again on CNN.com with 2001101212 linux, after not seeing any problems at all for some time. And it still doesn't happen for me with the test case.

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

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

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

This happened to me today using Linux build 2001101513: 1. Start Mozilla at my default start-up page. 2. Go to cnn.com 3. Click on an article at cnn.com 4. Go back to the cnn front page My session history under "back" button is filled with 8 entries of cnn.com! The session history under the forward button is empty, even though the forward button is enabled. When I tried to skip those duplicate entries and back to my start-up page, cnn.com loads instead. Then I hit "reload" and my home page showed up. 100% reproducible on my computer. Really weird and annoying.

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

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

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

This issue is clearly associated with tracking history across frames in a frameset.

I could reproduce the original problem described here on a build from 10/02. But I can not reproduce it in today's trunk. However, symptoms of the problem are in the 0.9.5 branch. I will be looking in to the branch more closely.

In today's trunk build, 1) I can not reproduce the problem with the first testcase, (id 53293). 2) I can not reproduce the original problem reported in cnn.com 3) In the second testcase attached, (53779), back forward buttons in general work when going to frames.htm and clicking on 'go' in the subframe and clicking on 'back'in the second subframe. One problem I found is, when clicking on 'back' in the second subframe, the forward button does not enable. I think this problem is unrelated to the original problem regarding cnn.com. There are some problems in the 0.9.5 branch though. I'm investigating ...

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

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

I just had it happen on CNN.com with build 2001101608 (linux) on FreeBSD. I went to an article, and when I hit back, I was about three hops back in my history. If I recall correctly, my history was: Cnet.com article Wired.com CNN.com main page CNN.com article When on CNN.com article, I hit back and ended up on Cnet.com article (it skipped cnn.com main page and wired.com).

I have had a similar problem with 0.9.5 linux i686, as the one with the "skipping backwards in history" as in Sean Harding's post. In addition, when I go to cnn.com and click on the go menu, the selected item is the page in my history. So, if my go menu might look like CNN o Google Even when I'm on the CNN webpage.

Just now, loading CNN.com (main page) and hitting back took me EIGHT PAGES back in my history. They didn't show up in the back button dropdown at all. Yet, going forward from there took me back through all of them again. And after going forward through all of them until I landed on CNN.com again, the back button functioned normally.

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

Like I explained earlier, this is happening because of expired pages. Currently the primary cnn site (www.cnn.com) is a expired page, probably because content is changing so fast. The fix I had put in for expired pages on Oct 9 for bug 99305 has fixed the problem in the trunk. However that patch did not make it to the 0.9.5 branch. So, the original problem described here exists in the branch and not in the trunk. I will look at the other examples provided here.

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

When I download from http://ftp.mozilla.org/pub/mozilla/nightly/latest/ am I getting the trunk or the branch build? I still see the problem on CNN with Win2K build 2001101603.

The patch attached to bug 101682 takes care of the problem #3 I described at today 2001-10-16 12:28

Erin: /pub/mozilla/nightly/latest/ is the trunk.

If that's the case, and I'm understanding Radha to be saying that this is supposed to be fixed in the trunk since Oct. 9, then we have a contradiction. This problem still exists in the nightly build I downloaded today. Am I misunderstanding something, or is there a contradiction here?

Confirmed on Win2K, build 20011016.

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

the huge number of different results sounds like a timing problem to me. radha, could you test a slow machine? I myself work on a remote X display, and it's very reprocable. (if I wouldn't use ns4 by now to surf CNN :-( )

I am getting this intermittantly most of the time -- maybe there are several back-button related bugs involved here. The strangest thing that happened to me recently was within a framed site with several open windows. In each of the windows there were different pages of the same site, but obviously with identical frame and html structure. Back button worked perfectly, but after the 9th or so window I opened the back button stopped working in this window. Also for any additional windows I opened. It continued working in the windows I opened before the 9th window.

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

I do see the following problem: 1) Go to cnn.com 2) Click on a story 3) Click back. 4) Before the main page is rendered, (while the throbber is still throbbing) click forward 5) Click on the go menu. You see multiple entries for cnn.com. I will look in to this. I still believe that the original problem described here is contained.

It may be contained, but it's not fixed in build 2001101708 linux.

I just upgraded from a 10/8 build to 2001101503 and can no longer reproduce the original problem. I do see the duplication problem Radha mentioned (I used the Go menu for that test, and I've seen this problem on other sites).

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

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

Another site that this can be demonstrated on is ... http://www.soyousa.com/ Click on the link with the text... Sep, 25, 2001 VR-Zone Hardware review on SY-P4ISR <http://www.soyousa.com/pix/new2.gif> "The most prominent function of this board is the Smart Card Reader. It offers more functions like the Mighty Bolt to increase security of your system." It takes you to another page, and then the back button does not get you back.

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

resummarising to minimise dupes.

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

I have attached a patch that takes care of the original problem described here (in a different way) and the other problem I had described at 2001-10-17 12:40. (Clicking back forward fast creates multiple entries for cnn.com). can someone try the patch and update the bug. I tried the patch on my linux 6.2 machine P3 500 Mhz and could not reproduce the multiple entries problem.

patch applied to trunk build from last night on win2k: this works for me. I can't reproduce the problem I noted in bug 105345, and clicking back and forward rapidly does not confuse the history, or create duplicate (or missing) entries.

Well, this seems to work for me when applied to a trunk build from Oct 18th.

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

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

I would like some broader testing with subframe navigation with this patch. Can someone try a bunch of frameset sites including javascript based history.back()/forward(). I have sone some testing, but would like a wider audience to give it a shot. Thanks,

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

Hi Radha, the code looks good but can you just verify that your logic to use the parent's docshell to determine the load type for subframes is suitable for when the parent and the child are of different types? For example, if the parent item is a chrome and the child is content. I don't think the old code did anything about this either, but the code should treat content with a chrome parent as if it is the topmost frame.

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

Adam, we do not want to enter that part of code when the parent and child are of different loadTypes. That is why, we call GetSameTypeParent(). The older code also did that.

r=adamlock I should have seen that call to GetSameTypeParent...

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

I'm seeing slightly different behavior than that described here. Using 0.9.5 on Win 95. Go from page n to http://www.cnn.com. Click on "Pentagon calls Taliban '**** liars'." Click on drop back button drop-down arrow, first item in history is page n - 1. Hit back button and I'm taken back to page n - 1. Click on forward button dropdown arrow, and page n is the first item, www.cnn.com is skipped, and the next item is the one where a high-ranking defense official tells Mullah Zaeef "elif air ab dinich!" I think it's an Al-Qaeda plot!

radha, tested your patch on my setup, fixes CNN. (Don't dare to say anything about the code though, it's far out of my reach.)

jvance, the problem in its original form and all its manifestations exists in 0.9.5 and I can't fix it there anymore. The fix I have posted will be applied to the trunk and will be there in 0.9.6.

hey radha... it looks good to me :-) sr=rpotts@netscape.com shouldn't GetLoadType(...) be prototyped with NS_IMETHODIMP *not* nsresult tho' ?

Fix checked in.

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

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

build ID: 2001102808 somewhat improved behavior, but not fixed 1. goto www.cnn.com 2. click on link A 3. now on link A, go back to www.cnn.com 4. click on link B 5. now on link B, go back to www.cnn.com 6. bug: you end up on link A, not www.cnn.com. At this point, if you go back, you stay on link A. I tried this several times with different links with the same behavior.

this behavior is afflicting sites other than www.cnn.com.

Kyle: You're seeing smoketest-blocker bug 107097, not this bug. -> FIXED

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

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

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

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

I have the similar problm with http://f1.racing-live.com/en/. I can't even open the page with Javascript disabled. I'm using Mozilla 0.9.9+ 20020411

(WinXP, build: 2002053012) http://f1.racing-live.com/en/ CONFIRMED, the back button is greyed out if I visit a link. BUT this is only reproducable if you start with a clean tab or a clean window (i.e. no previous history), if you visit some other site first, and then go to http://f1.racing-live.com/en/ (in the same window/tab) and then click on a link - then the history works as it should.

I'm really sorry for spamming, but the history does not work alright. :) Case A: 1) Go to http://f1.racing-live.com/en/ 2) Click on a news link Case A behaviour: History back is greyed out and empty. Case B: 1) Go to any site, like mozilla.org 2) Paste in http://f1.racing-live.com/en/ in the address field and go there 3) Click on a news link 3) Go back one step - you will be at mozilla.org 4) Go back one step more - you will be on one of the subframes of http://f1.racing-live.com/en/ (looks really weird)

As this bug has been resolved, I have opened a new bug, bug 153165 for this issue.

And this is also related...: bug 170798

verified fixed