Closed Bug 116361 Opened 23 years ago Closed 23 years ago

The site keeps reloading all the time, when it shouldn't

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 124103
Milestone:
mozilla0.9.9

People

(Reporter: artem.goutsoul, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(3 files)

testcase
341 bytes, text/html
Details
another testcase
342 bytes, text/html
Details
intervals overflows causing repeated refresh events
710 bytes, patch
Details | Diff | Splinter Review 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase — 
[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.
Keywords: testcase
Blocks: 100951
No longer blocks: 100951
darin
Assignee: neeti → 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!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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...
OS: Windows 2000 → All
Hardware: PC → All
Attached file another testcase — 
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.
Keywords: mozilla0.9.9
-> 0.9.9
Status: REOPENED → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
-> badami to investigate
Assignee: darin → badami
Status: ASSIGNED → NEW
*** 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.
Assignee: badami → pavlov
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Vinay, you are right. PRTime would be the best long term solution.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: