Sites like: www.kpnews.com www.korespondent.net www.uasport.net keep reloading all the time, when they shouldn't. This slows down everything a lot. This never happened until a couple builds ago. But started happening in at least 20011217 and is still happening in 20011220. The bug prevents browsing of these sites since it's impossible to read anything while it's reloading. On www.uasport.net it even prevents loading of the images (they load fine in all the other browsers, and loaded fine in Mozilla before). The problem seems to be related to Refresh or Expires meta tags in the head if the documents.

All three sites contain this tag: <META HTTP-EQUIV="Refresh" CONTENT="28800">

works fine for me. (build 20011220 06). but, how often does it refresh - seconds? although bug 78914 looks the same, it relies on window.location and plugins.refresh, which isn't true for the sites suggested. reporter: anyhow, take a look at that bug.

I see this too, win98SE, 2001121909. Confirming. Not sure that it's networking though. The page seems to load, then immediately either reload, or redirect to another URL, often http://www.bigbn.com.ua/f.php?p=8813&t=4&n=2811465 [the numbers change, I think they're random] [knocks up test case] It's the meta-refresh tags. I'll attach my test case in a mo.

[caution, on my system, when the problem is triggered, the whole mozilla process becomes unresponsive - it will accept events eventually, but things GRIND] Now this is where things get really freaky. I spent some time playing with the meta-refresh value to try and figure out the boundary where things go pear-shaped. Knowing that it did instant refreshes at 28800 (the value at the URL above) but worked fine at 5, I started testing values in between. The first time I tried 21750, it didn't instantly refresh, but 22000 did. So I started working through the values in between, and found that 21751 did instantly refresh. And so did 21750. So, it's a moving target. I'm betting that the trigger value is different for different people, too.

wislam, bug 78914 goes away when javascript is turned off, but I've managed to produce a testcase for this that doesn't involve JS, so I think this is a different problem.

darin

No refreshing here, with 2001122108 Linux.

OK, I can't reproduce this with 2001122703, Win98SE. agutsul@hotmail.com, any chance you can re-test with a more recent build, and let us know how you get on?

Using a clean 2001122803 build with a new profile (win2k) - the problem persists. http://www.kpnews.com/ exhibits a very weird behaviour: now it doesn't constantly reload but still eats up a lot of resources, and slows down mozilla. Flash banner overlays text. www.korespondent.net and www.uasport.net both behave as they did before (see the first description). Now for the interesting bit - I tried this on another win2k machine, everything seems to work fine there... I don't know what could be so special about my machine that it doesn't work here. Both machines are in the same network (i.e. pretty much the same network settings). The only Mozilla related difference I could think of is an old installation of Netscape Communicator 4.77 on my machine. But I also tested the case with the Communicator removed (problem persists).

I wasn't able to reproduce any of the problems I mentioned above using a more recent build - 2002010403. I hope the bug is gone for good ;).

marking WORKSFORME, reporter please reopen this bug if you notice the problem again. thx!

I hope this is gone for good, too, but bug 122328 sounds awfully familiar...

Well, I'm sorry to say it, but after a couple builds I do see the bug again. It probably didn't go anywhere, since the bad part is that I can't reproduce it consistently. It happens about 80% of the times. Same build, same profile, same everything. The only consistent thing is that it only happens on the sites that I mentioned. So far I haven't seen any other sites producing the same effect. It would be good if someone else could reproduce it to compare observations.

shar: what is the most recent build w/ which you have observed this problem?

Build 2002012304. I will download the most recent one right away and test it on it too.

great! and if you can repro the problem please generate a HTTP log like so: 1) open DOS prompt 2) set NSPR_LOG_MODULES=nsHttp:5 3) set NSPR_LOG_FILE=c:\http.log 4) cd \path\to\mozilla 5) .\mozilla.exe 6) repro problem 7) submit c:\http.log to this bug if you could do this it would help us determine the cause of the problem. thx!

Alright, I made a log of the problem with build 2002012903: The file grew large in a matter of seconds - 3.5 megs, so I decided not to attach it directly. You can get it from: http://microdata-int.com/mozilla/http.log Please tell me when you downloaded it, so that I can remove it. You can probably then select the relevant parts of it and attach it to the bug.

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

I do not see this problem on any of the things mentioned here, but I do see it on http://www.cs.cornell.edu/ - there Mozilla just keeps constantly reloading something, but never shows anything at all! I see this on several RedHat Linux 7.2 machines running 0.9.8 release and BuildID 2002020218 (trunk). I am not sure whether it's the same bug or not, though...

OK, now I am sure it's the same bug I am seeing. While the testcase in attachment 62511 [details] does not cause Mozilla to exibit this behavior, if I change <meta http-equiv="refresh" content="21600"> to <meta http-equiv="refresh" content="604800"> (e.g. just changing the number), I immediatelly see this problem...

This is the testcase that triggers this bug for me.

Yes, if I just click on attachment 68358 [details], Mozilla goes into reloading it forever... It does give me a chance to see contents once in a few reloads, but most of the time it is just showing me a blank screen.

-> 0.9.9

-> badami to investigate

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

This keeps re-surfacing. I duped the older bug to this because some of the links were updated and this bug is a little more active. Maybe it will get fixed here. I can reproduce this using build 2002020603 on winNT4.

In void nsTimerImpl::SetDelayInternal(PRUint32 aDelay) PRIntervalTime now = PR_IntervalNow(); mTimeout = now + PR_MillisecondsToInterval(mDelay); mTimeout can overflow. The code I have caps mTimeout to PR_INTERVAL_NO_TIMEOUT. To fix this the correctly, we may need to add a PRInt64 to each timer. Comments/Suggestions ?

timers are pavlov.

IMHO the number of sites that seem to be triggering this bug indicates that we'd better support such bug refresh timeouts, not just ignore them...

This would not ignore them. With the test case 604800 secs is 168 hours. We would be causing the refresh once in approx 6 hours.

pavlov: see comment #27

nsTimerImpl seems to hold the time at which it needs to fire. Rather if it held two - timestamp when the delay was set and the delay, then in the thread that fires timers, we could do something like if (Now > timer->timerSetTime + timer->delay) timer->fire(); I guess that is effectively holding a 64bit int without the 64bit arithmetic.

FWIW, I started seeing this problem on morons.org with build 2002020406. Morons.org does send a Refresh: header of 3600 seconds, but doesn't use a meta refresh tag.

Suresh Given that Now is a 32 bit number and (timer->timerSetTime + timer->delay) can be > 32 bits, the check of (Now > timer->timerSetTime + timer->delay) may not succeed. I think the basic problem here is that we are using PRIntervalTime to denote an absolute time on the time scale when the timer should fire.

I guess we will be ok if we were to be using PRTime instead of PRIntervalTime and use the LL_ stuff for aritmetic/comparisons. However, I'am a bit skeptical of making this change since there maybe a (and probably is) performance impact of going from PRIntervalTime to PRTime.

Pavlov This is in your area. If u have suggestions of how to fix this, cut in your comments and I can take it from there if u do not have the cycles.

Vinay, regarding your comment 34, you are right about the overflow situation. How about: Now - timer->timerSetTime > timer->delay That should take care of it and we can escape using 64bit computations.

Ccing Vinay Badami. Vinay see my earlier comment 37.

Suresh No i do not think that this would work either when the delay is large. From http://www.mozilla.org/projects/nspr/reference/html/prinrvl.html#20943 "The increasing interval value represented by PRIntervalTime wraps. It should therefore never be used for intervals greater than approximately 6 hours." and a bit further in the same document "Waiting on events more than half a day in the future must therefore be based on a calendar time."

dup *** This bug has been marked as a duplicate of 124103 ***

Vinay, you are right. PRTime would be the best long term solution.