Closed Bug 40072 Opened 25 years ago Closed 24 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: 25 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: 25 years ago → 24 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: 24 years ago → 24 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: