Closed Bug 103978 Opened 23 years ago Closed 23 years ago

back button does not take you back in cnn.com

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: rgoldiez, Assigned: radha)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: regression, Whiteboard: mostfreq)

Attachments

(4 files, 2 obsolete files)

Testcase
551 bytes, text/html
Details
Simple frameset test case. Run frames.htm
454 bytes, application/octet-stream
Details
Simple frameset test case. Run frames.htm
454 bytes, application/octet-stream
Details
updated patch
7.56 KB, patch
Details | Diff | Splinter Review 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
OS: Linux → 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.
Component: Browser-General → Javascript Engine
that's not a valid reason to use that component, please read the descriptions 
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Assignee: asa → radha
Component: Javascript Engine → History: Session
QA Contact: doronr → claudius
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...
Attached file Testcase — 

    
    

    
  
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.
Blocks: 101793
Keywords: regression

    
    

    
  
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. ***

    
    

    
  

      
      
      
      

        Attached patch
          
          
        possible patch (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
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. 
Status: NEW → ASSIGNED

    
    

    
  
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. ***

    
  
Blocks: 104864
Target Milestone: --- → mozilla0.9.6

    
    

    
  
*** 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. ***
Summary: back button does not take you back to the previous page... → back button does not take you back in cnn.com

    
    

    
  
resummarising to minimise dupes.
Whiteboard: mostfreq

    
    

    
  
*** 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. ***

        Attachment #53338 -
        Attachment is obsolete: true

    
    

    
  
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. ***

        Attachment #54142 -
        Attachment is obsolete: true

    
    

    
  
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. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
*** 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
    

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

-> FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → 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. ***
No longer blocks: 104864

    
  
Blocks: 104864
No longer blocks: 104864

    
    

    
  
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
Status: RESOLVED → VERIFIED

    
  
Blocks: backtraps

    
  
Component: History: Session → Document Navigation
QA Contact: claudius → docshell

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: