Closed Bug 40072 Opened 24 years ago Closed 23 years ago

endless loop in jumping from page to page?

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: mgsp, Assigned: harishd)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [pdt+][nsBranch+][fixed and verified on trunk])

Attachments

(2 files)

patch
1.91 KB, patch
Details | Diff | Splinter Review
patch v1.2 [ addressing vidur's concern ]
1.89 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; I; Linux 2.2.14-5.0 i586; Nav)
BuildID:    2000041805

Mozilla seems to enter endless loop while trying to load
http://www.icl.ndirect.co.uk/music/music_welcome.html
NS4.72,w3m both work fine.

Reproducible: Always
Steps to Reproduce:
1. go to http://www.icl.ndirect.co.uk/music/music_welcome.html
2.
3.

Actual Results:  the page never came out, mozilla kept jumping from one page to
other

Expected Results:  http://www.icl.ndirect.co.uk/music/index.html, loaded
WORKSFORME Linux build 2000051908
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
reopening. I see this, the page keeps reloading.  Could be realted to frames and
meta refresh. Asa, you see this as well? Marking os all, seen on win98
2000060808 build.
Status: RESOLVED → UNCONFIRMED
OS: Linux → All
Resolution: WORKSFORME → ---
confirmed on mac and win 060908 M17 trunk moz bits build.  confirming updating
component and setting default owner.
Assignee: asa → gagan
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → tever
there seem to be multiple timers firing off. Can someone check the page contents 
to see if there is more than one META refresh, javascript document.location, or 
HTTP Refresh? Its possible that a bad combination of these is resulting in our 
looping.
Keywords: helpwanted
Target Milestone: --- → Future
Blocks: 61693
The given url http://www.icl.ndirect.co.uk/music/music_welcome.html is no longer   
valid. 
Reporter,
Please submit a valid url.

Neeti

Updating url to http://www.un4seen.com based on reporter's mail
URL: http://www.icl.ndirect.co.uk/music/mu... → http://www.un4seen.com
We need to find contents of pages 
http://www.un4seen.com/music/music_welcome.html   and
http://www.un4seen.com/music/index.html to check if check if there is more than 
one HTTP refresh.

nsRefreshTimer::Notify is triggered multiple times.
Changing milestone to mozilla0.9. Need some help to find out content of pages, 
if multiple timers are going off.
Target Milestone: Future → mozilla0.9
I'll look at this tomorrow (but I'll trade that info for a fix to the 'simple
redirects never finish loading' problem :-]
Okay, so here is a simplified form of these pages. It is posted in working
form at http://jrgm/bugs/40072/index.html with a few dump statements added.
 
I think this could be even further simplified, but, at any rate the deal is 
that the top level document 'index.html' pulls in some JS that writes a 
frameset into the current document. But a 'meta refresh' that was included in 
the original document is not cancelled and will fire in 9 seconds.
 
The loop happens because the 'meta refresh' loads the right hand frame, which
in turn does a window.location = 'index.html' if it is not inside the frameset
(which writes in a new frameset and sets another 'meta refresh', and so on,
and so on ...).
 
 
 
---------- index.html --------------------
<html>
<head>
  <script language="JavaScript" src="index.js"></script>
</head>
<body>
  <meta http-equiv="refresh" content="9;URL=music_welcome.html">
</body>
</html>
 
 
 
---------- index.js --------------------
var frametoload="music_welcome.html";
document.write('<FRAMESET COLS="130,*" framespacing=0 FRAMEBORDER=0 border=0>');
document.write('<frame name="Index" src=music_index.html MARGINHEIGHT=10 ');
document.write('MARGINWIDTH=0 NORESIZE SCROLLING=NO><frame name="Body" src=');
if (window.dump) dump(document.cookie + "\n");
if (document.cookie.indexOf("frame=")>-1) {
  frame=document.cookie;
  frame=frame.slice(frame.indexOf("frame=")+6);
  if (frame.indexOf(";")>-1)
    frame=frame.slice(0,frame.indexOf(";"));
  if (frame)
    frametoload=frame;
  document.cookie="frame=";
}
if (window.dump) dump(frametoload + "\n");
document.write(frametoload);
document.writeln(' MARGINHEIGHT=10 MARGINWIDTH=40></FRAMESET>');



---------- music_index.html --------------------
<html>
<body>
  <p>This is the left hand "index" frame</p>
</body>
</html>



---------- music_welcome.html --------------------
<html>
<head>
  <script language="JavaScript" src="music.js"></script>
</head>
<body>
  <p>This is the main body frame.</p>
</body>   



---------- music.js --------------------
if (window.dump) dump(window.location + "\n");
if (window==top) {
  if (window.dump) dump('window == top\n');
  document.cookie="frame="+window.location;
  top.location.replace("index.html");
}


Related : bug 32049
->0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Turns out this was related to the fix in 32049. Marking as such...
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
No. Either the reported URL http://www.un4seen.com, or the simplified test
case at http://jrgm/bugs/40072/index.html, will endlessly reload due to a
meta refresh element in the body of the initial URL (2001051813 win2k).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
strange.... both the cases work for me on linux... will have to investigate on 
windows :-(
Actually, it's much more subtle now that we (er, hyatt) keeps the previous
document showing while the new one loads. But, if you watch the console, 
progressmeter or statusbar, you'll see that they update every nine seconds
for either www.un4seen.com, or my simplified test case.
... and what I forgot to say, was that I see this on both win2k and linux.
mass move, v2.
qa to me.
QA Contact: tever → benc
I can't see the problem on the test url, but it is visable
on jrgm's test case.  does anyone think this is still
milestone stopperish?
I suppose this doesn't really block 0.9.1, but I'm leary of leaving this
uncancelled redirect hanging around; some major site is going to get bit
at some point.

Here's the minimum test case:

<html>
<head>
  <script>
    document.write('<frameset rows="100%,*">');
    document.write('  <frame src="http://www.mozilla.org/">');
    document.write('</frameset>');
  </script>
  <meta http-equiv="refresh" content="5;URL=http://bonsai.mozilla.org/">
</head>
</html>
Whiteboard: wanted for 0.9.1 no patch yet
I still can't reproduce this problem (neither the URL nor the minimal case) on
linux (don't have a m/c to try it on Win2K) At this stage I am inclined to say
it's safe to not make this be a beta blocker. 
That's odd, since the testcase http://jrgm/bugs/40072/index.html works 
(i.e., loops every 9 seconds) for me on redhat 6.1 with 5/28 build.

Nonetheless, as I noted earlier, I don't think this is a beta-stopper either.

(But an uncancelled timer just gives me an uneasy feeling, so I don't really
want to see this punted to Future).

[I should note that that last, minimal test case, is "by the letter" ambiguous
as to how it should behave, but existing browser's will cancel that meta 
refresh when the frameset is written into the document.]
Whiteboard: wanted for 0.9.1 no patch yet → wanted for 0.9.1 no patch yet (punt to 0.9.2??)
I agree that its really odd and inconsistent behaviour. And I also agree that we
don't want to leave this bug for future... I plan to continue working on
tracking this down. After talking to chofmann I am moving this bug off to 0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 83471 has been marked as a duplicate of this bug. ***
Whiteboard: wanted for 0.9.1 no patch yet (punt to 0.9.2??)
After talking with Nisheeth, I am still not convinced that the meta tag should 
not be processed. However I'd let the frameset-guru Eric make the final call on 
it. If the frameset loading is supposed to abort the current doc completely then 
we need to figure out why the timer is not being canceled. Otherwise I think we 
are doing the right thing here... over to Eric. (and also moving this out to 
0.9.3)
Assignee: gagan → pollmann
Status: REOPENED → NEW
Target Milestone: mozilla0.9.2 → mozilla0.9.3
See also bug 82498, where we stopped handling of the <script> tag after a
<frameset> tag had been encountered for compatability.  Handing this one to
Harish, because I think it's the same deal, but with ProcessMETATag instead of
ProcessSCRIPTTag.  ???

I tested with Nav 4.x and IE 5.5, and neither process the <META
HTTP-EQUIV=REFRESH>.  I have not tested other HTTP-EQUIV's, but I assume (famous
last words) that they are also not processed.
Assignee: pollmann → harishd
Attached patch patch — — Splinter Review 

    
    

    
  
Ew! You're nuking the ability to set _any_ http-equiv? So people can't set
some headers like 'Expires: -1' or 'Pragma: no-cache'. I don't think you 
want to do that. Nav4.x honors (at least) the 'Pragma: no-cache' when set
in the head of a frameset document. 

    
    

    
  
This patch would only affect <meta>'s that came 'after' the <frameset>, so a
pragma: no-cache that came in the head would still be processed.

    
    

    
  
Ah. Oh. Nevermind then :-]

    
    

    
  
Thanx Eric :-) r=harishd
Status: NEW → ASSIGNED
Whiteboard: [fix in hand]

    
    

    
  
1) I don't understand the if (!mDocument) clause. Under what circumstances would
we not have a document available to the sink?
2) The comment implies that we never process META elements in a frameset
document. Change it to say that we don't process META elements after a FRAMESET
element is encountered.


    
    

    
  
sr=vidur.

    
    

    
  
Fix checked in to the TRUNK.

    
    

    
  
Previous comment was from me not vidur's :-)

    
  
Keywords: vtrunk

    
    

    
  
Verified FIXED on today's trunk builds on Win2k and Linux.
Whiteboard: [fix in hand] → [fixed and verified on trunk]

    
    

    
  
Very safe, very targeted fix.  Marking nsBranch+ for PDT consideration.
Whiteboard: [fixed and verified on trunk] → [nsBranch+][fixed and verified on trunk]

    
  
Whiteboard: [nsBranch+][fixed and verified on trunk] → [pdt+][nsBranch+][fixed and verified on trunk]

    
    

    
  
Checked into branch on behalf of Harish. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
ben - pls verify this on the branch builds. Thanks.
Keywords: vtrunk → vbranch

    
    

    
  
verified fixed, 7/20 branch and trunk builds, mac/linux/win32 against the 
testcase I posted above, and against www.un4seen.com

Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: