JavaScript keeps periodically reloading page element, even if page is no longer displayed




JavaScript Engine
16 years ago
16 years ago


(Reporter: Christian Hamacher, Assigned: rogerl (gone))



Firefox Tracking Flags

(Not tracked)




(1 attachment)



16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030226
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030226

This page conatains an area where users can leave messages ('tag-board'). While
the page is being displayed, periodic reload of the tagboard takes place - this
is correct behavior so far.
However, if I leave the page (doesn't matter if I close the tab, close the
window, enter another URI, close all instances of the navigator window, etc.),
there ist still periodic network activity. Ethereal shows that the tagboard is
still being reloaded approx. every 18 seconds, even though the page is not being
displayed anywhere.
As soon as I completely close Mozilla, the periodic network activity stops. If I
restart it, there is no activity. As soon as I visit the site again, the problem
starts again.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla
2. Visit URL
3. Leave URL, by whatever means you like (closing tab, closing window, ...), but
leave Moz running
4. Use tcpdump, ethereal etc. to observe periodic network activity
Actual Results:  
Reloads of tag-board take place, even if the URL is not being displayed anymore

Expected Results:  
The tagboard shold reload while the page is displayed, but the reloads should
stop as soon as the page is not displayed anymore.

If you search for 'name=AlienDice' in the page source, you find the DIV that I
believe to be responsible for the reloads:

<div align="center"> 
 <script language="Javascript" type="text/javascript"
 <table width="100%" cellpadding="2" cellspacing="0" border="0">
  <td width="400" height="300" valign=top> <iframe
src="" name="tag" width="550"
height="300" marginwidth="0" marginheight="0"></iframe> 



I have tried several things in order to narrow down the potential source of the

o disabling disk- and mem-cache has no effect
o HTTP/1.0 or HTTP/1.1 makes no difference
o switching off keep-alive makes no difference
o Accessing the URL via a local squid proxy or directly makes no difference


o Disabling JavaScript makes the problem disappear

(BTW: based on this last observation - and only on this observation - I have
filed this under 'JavaScript Engine'. This might be completely wrong)

I'm on a demand-dialling connection that gives me visual feedback on link state
- the reloads keep the link from ever going down once I have visited the
problematic site. This is how I discovered the problem. Unfortunately, I cannot
put a precise date on when the problem appeared. I have definitely seen it for
the last one or two weeks, but only got around to digging for the source today.
However, since the problem doesn't really show when I close Moz after my
session, it might be even older, and I might just have missed it for some time
(anxiously waiting for my ISP's bill for this month ... :-/)

I build Mozilla from source fairly regularly (at least once a week - trunk
builds). I'm *almost* sure that the problem wasn't there before the branching
for 1.3. But that's about as good a guess regarding the time frame as I can
provide now.

I'm filing this as 'Major', since I believe that a lot of people have demand
dial connections, and they pay money if the link is not going down appropriately. 

Could somebody who has older builds available please check and possibly confirm
this? Are other people seeing this at all?

Comment 1

16 years ago
Created attachment 116025 [details]
Saved Ethereal trace (libpcap format) of the spurious link activity

I'm attaching a trace done with ethereal, and saved in libpcap format. This
trace shows the repeated HTTP GET request.

BTW, if anybody can suggest a more concise wording for the summary, please by
all means do so!

Comment 2

16 years ago
This looks like a dupe of bug 194994. The iframe seems to load with a settimeout
that is not killed when the iframe is unloaded. (see and 

Reporter, if you agree it's a dupe, could you please mark it such.

Comment 3

16 years ago
Oh boy - yes, this indeed seems to be a duplicate.

Since the settimeout in the JavaScript is exactly the 18 seconds reload time I
observed, and since the whole thing is in an iframe, I'm sure James is right.

Thanks for catching this so quickly!

*** This bug has been marked as a duplicate of 194994 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 4

16 years ago
Verified Duplicate -
You need to log in before you can comment on or make changes to this bug.