Too many progress messages generated for animated GIFs




18 years ago
17 years ago


(Reporter: David Hyatt, Assigned: Stuart Parmenter)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
Load the above URL in Netscape 6.  After it has fully loaded, you will see that 
we continue updating the status bar ad infinitum, continually informing the user 
for each new frame of the animated GIF that we fetch.

Load the same page in 4.x.  You'll see that no progress messages are generated 
as subsequent frames of the animated GIF load.

Comment 1

18 years ago
Nominating for nsbeta3.  This affects several sites I visit regularly.  Maybe 
it's more of an animated GIF problem, but  - whatever the root cause - it slows 
down the whole UI and makes it hard to scroll the page, etc. etc.

Keywords: nsbeta3

Comment 2

18 years ago
I'm guessing that what needs to happen here is that imagelib should implement 
the nsIProgressEventSink and intercept messages from the underlying channel and 
squelch them. Reassigning to Gagan.
Assignee: warren → gagan

Comment 3

18 years ago

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

Comment 4

18 years ago
I'm closing bug #5030 and reopening this one.
Bug#5030 was closed 6 months ago.

After 6 months, a similiar symptom is apt to have
a very differnt cause.
Resolution: DUPLICATE → ---

Comment 5

18 years ago
*** Bug 48754 has been marked as a duplicate of this bug. ***

Comment 6

18 years ago
If this is going to be used in place of 5030, it should be noted here that this
actually DOES generate a server hit for each iteration of the animated GIF.
I've tested it with an animated GIF off my own server, and noticed a GET w/304
reply on each repeat.

I'd call this a bit more serious because of this... on a page with a moderate
number of short-duration animated GIFs, Mozilla essentially bombs the server
checking them again and again.


18 years ago
Target Milestone: --- → Future

Comment 7

18 years ago
*** Bug 49194 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
49194 is reported on Mac and i see this on Linux as well - changing platform/OS
to ALL.
OS: Windows 98 → All
Hardware: PC → All

Comment 9

18 years ago
*** Bug 49234 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
This is a really serious problem because, on my dialup connection, my bandwidth
is totally swamped with I-M-S requests and responses on pages with many
animations, such as  Moreover, as has already been noted, we are not
being good net.citizens when making requests in a tight loop.

Finally (and worst), even if the origin server starts responding with HTTP 200
and sending the changed GIF body, Mozilla continues to make I-M-S requests with
the original response date.  Therefore, this occurs:

t + 0: Mozilla makes request
t + 1: Origin server sends HTTP 200
t + 2: Mozilla make if-modified-since request with Date: t + 1
t + n: Data changes on origin server
t+n+1: Mozilla make if-modified-since request with Date: t + 1
t+n+2: Origin server responds with HTTP 200 and body
repeat last two steps, transmitting image body over and over again...

So you can see this is quite a serious problem.  Left alone on the desktop
overnight, Mozilla is going to send a lot of bytes over the wire.  In many parts
of the worls, bytes == money.

Comment 11

18 years ago
This is one of the problems we have been discussing with the image cache. cc'ing 
relevant people and making this a plus.
Whiteboard: [nsbeta3+]


18 years ago
Target Milestone: Future → ---

Comment 12

18 years ago
*** Bug 49757 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
This seems to be fixed in Linux 2000082121.  Can anyone confirm?

Comment 14

18 years ago
Problem still exists in Linux 2000-08-21-21.

Comment 15

18 years ago
My check in yesterday would have fixed this so that
the user pref for loading is applied when a load normal
is issued to the imagelib.

Gagan, I'm reassigning to me and closing the bug. 
Let me know if you would rather handle this another
Assignee: gagan → pnunn

Comment 16

18 years ago
Checkin for bug#20110 fixed this bug.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
That fix should be in the Linux 2000-08-22-08, but the bug is still present.
Mozilla makes continuous requests for advertisements and other animated GIF
whenever I visit cites like  Do I misunderstand the bug?  I think this
need reopening....

Comment 18

18 years ago
I am not seeing this problem anymore on Linux 2000082121...

Comment 19

18 years ago
This is not the right fix. We should never get loadNormal for animation loops. 
See related bug 46146
rpotts: we desperately need to get this fixed in docshell/loadgroup etc.
Resolution: FIXED → ---

Comment 20

18 years ago
I'm attaching some diffs which do three things:

1. Changed the DiskCacheRecordChannel and MemCacheChannel to implement 
Get/SetLoadAttributes.  It used to be that nsCacheEntryChannel had the 
implementation.  This was wrong, because the CacheEntryChannel was an 
intermediate channel which was not always used.

2. Changed the Set/GetLoadAttributes implementation in nsCacheEntryChannel to 
delegate down to the underlying cache transport (ie. nDiskCacheRecordChannel).  
This ensures that all of the cache channels have a consistant idea of what the 
LoadAttributes are :-)

3. Changed the implementation of nsHTTPChannel::GetInterface() to *not* return 
an nsIProgressEventSink if the channel has the LOAD_BACKGROUND attribute set.
This was the easiest way to suppress notifications from the SocketTransport.  It 
also eliminates the unnecessary proxied notifications that were being generated 
(and ultimately supressed)...

Let me know what you think of the changes and I'll check them in when the tree 

Comment 21

18 years ago
Created attachment 13373 [details] [diff] [review]
patch file...

Comment 22

18 years ago
I'm asking Neeti to scan the patch. 
I'm a novice when it comes to necko cache.

Comment 23

18 years ago
I just talked to Neeti, so we are all on the same page.
I'll be testing your patch in my local tree as soon as
my tree finishes rebuilding.

Comment 24

18 years ago
I removed the code I added monday to mozilla/gfx/src/nsImageNetContextAsync.cpp
in ImageNetContextImpl::GetURL() that gets the validation attribute from
the prefs.

And applied the patches attached to this report to mozilla/netwerk/cache.

And I still get 304's on animating gifs. I still get LOAD_NORMAL for the
channel when I call ImageNetContextImpl::GetURL() with a USE_IMAGE_CACHE
setting for the mReloadPolicy. 

Is there something else I should change when the GetURL is reissued for
the next animation loop?


Comment 25

18 years ago
The patch that I attached fixed a different problem (I think). 

These changes fix the situation where the HTTPChannel has the LOAD_BACKGROUND 
attribute and the URI is cached (in the DiskCache).  In this case, the 
LOAD_BACKGROUND attribute was lost and the DiskCacheRecordChannel used the 
default load attributes of the loadgroup :-(

I believe that the 304 being issued for animated GIFs is due to another 

Comment 26

18 years ago
ok. thanks for the clarification.

Comment 27

18 years ago
I've just checked in a bunch of changes which fix the issue of status messages 
being generated for channels that are loaded with the 
nsIChannel::LOAD_BACKGROUND flag (ie. animated GIFs).

Comment 28

18 years ago
I'm no longer seeing an if-modified-since request / 304 response for animated 

On the above URL, the image is consistantly loaded from the disk cache without 
ever hitting the network!!

Unfortunately, the CPU is *still* pegged :-(
I believe that it is now a layout problem.  If I scroll the page so the animated 
GIFs are not visible, I still see the data constantly being loaded from the 
cache, but the CPU is usage is very low.  So I'm guessing that since the image 
is not visible, layout is not reflowing...

Should we open up a new bug to deal with this issue?

-- rick

Comment 29

18 years ago
I have put in a change so that the new channel created for
the next loop of an animating image is set to VALIDATE_NEVER.

This is doing the RightThing when you have a page with an animating
image and replace the image on the page with another animating image.

A 304 is generated only when you hit reload for the tested page.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 30

18 years ago
It's fixed: linux 2000090208.
tcpdump show no reload of animated gifs through the net.

Comment 31

18 years ago
*** Bug 51529 has been marked as a duplicate of this bug. ***

Comment 32

18 years ago
(this is a followup to my bug report for bug 51529)

I'm still seeing GIFs reloading on Linux Build ID: 2000090508

Steps to reproduce:
1. start tcpdump - /usr/sbin/tcpdump -n tcp port 80
2. ./
3. load url:

(some) output from tcpdump:
blank lines added by me to emphasis time lapses is my address on the local net.

12:43:28.379896 eth0 > > P
193385651:193385931(280) ack 7572848 win 31856 <nop,nop,timestamp 24881236
62268601> (DF)
12:43:28.534159 eth0 > > F 280:280(0) ack 1
win 31856 <nop,nop,timestamp 24881252 62268601> (DF)
12:43:28.536170 eth0 > > S
412048126:412048126(0) win 32120 <mss 1460,sackOK,timestamp 24881252
0,nop,wscale 0> (DF)
12:43:28.660858 eth0 < > S
237742916:237742916(0) ack 412048127 win 32120 <mss 1460,sackOK,timestamp
14981110 24881252,nop,wscale 0> (DF)
12:43:28.661008 eth0 > > . 1:1(0) ack 1 win
32120 <nop,nop,timestamp 24881264 14981110> (DF)
12:43:28.661388 eth0 > > P 1:281(280) ack 1
win 32120 <nop,nop,timestamp 24881264 14981110> (DF)
12:43:28.830979 eth0 < > . 1:1(0) ack 281 win
31856 <nop,nop,timestamp 14981128 24881264> (DF)
12:43:29.152418 eth0 < > P 1:1449(1448) ack
281 win 31856 <nop,nop,timestamp 14981132 24881264> (DF)
12:43:29.152527 eth0 > > . 281:281(0) ack
1449 win 31856 <nop,nop,timestamp 24881314 14981132> (DF)
12:43:29.402650 eth0 < > P 1449:2897(1448)
ack 281 win 31856 <nop,nop,timestamp 14981132 24881264> (DF)
12:43:29.652235 eth0 > > . 281:281(0) ack
2897 win 31856 <nop,nop,timestamp 24881364 14981132> (DF)
12:43:29.662924 eth0 < > P 2897:4345(1448)
ack 281 win 31856 <nop,nop,timestamp 14981171 24881314> (DF)
12:43:29.682261 eth0 > > FP 0:280(280) ack 1
win 31856 <nop,nop,timestamp 24881367 62268601> (DF)
12:43:29.923048 eth0 < > P 4345:5793(1448)
ack 281 win 31856 <nop,nop,timestamp 14981171 24881314> (DF)
12:43:29.923191 eth0 > > . 281:281(0) ack
5793 win 31856 <nop,nop,timestamp 24881391 14981171> (DF)
12:43:30.032465 eth0 < > P 5793:6446(653) ack
281 win 31856 <nop,nop,timestamp 14981220 24881364> (DF)
12:43:30.052201 eth0 > > . 281:281(0) ack
6446 win 31856 <nop,nop,timestamp 24881404 14981220> (DF)

12:43:32.302185 eth0 > > FP 0:280(280) ack 1
win 31856 <nop,nop,timestamp 24881629 62268601> (DF)

12:43:35.895205 eth0 > > P 281:561(280) ack
6446 win 31856 <nop,nop,timestamp 24881988 14981220> (DF)
12:43:36.338553 eth0 < > P 6446:7894(1448)
ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF)
12:43:36.598856 eth0 < > P 7894:9342(1448)
ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF)
12:43:36.598972 eth0 > > . 561:561(0) ack
9342 win 31856 <nop,nop,timestamp 24882058 14981851> (DF)
12:43:36.788610 eth0 < > P 9342:10448(1106)
ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF)
12:43:37.049842 eth0 < > P 10448:11896(1448)
ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF)
12:43:37.218856 eth0 < > P 11896:12891(995)
ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF)
12:43:37.218951 eth0 > > . 561:561(0) ack
12891 win 31856 <nop,nop,timestamp 24882120 14981851> (DF)
12:43:37.542185 eth0 > > FP 0:280(280) ack 1
win 31856 <nop,nop,timestamp 24882153 62268601> (DF)

12:43:42.635137 eth0 > > P 561:841(280) ack
12891 win 31856 <nop,nop,timestamp 24882662 14981851> (DF)
12:43:43.094326 eth0 < > P 12891:14339(1448)
ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF)
12:43:43.354586 eth0 < > P 14339:15787(1448)
ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF)
12:43:43.354703 eth0 > > . 841:841(0) ack
15787 win 31856 <nop,nop,timestamp 24882734 14982525> (DF)
12:43:43.554334 eth0 < > P 15787:16893(1106)
ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF)
12:43:43.804910 eth0 < > P 16893:18341(1448)
ack 841 win 31856 <nop,nop,timestamp 14982526 24882662> (DF)
12:43:43.984614 eth0 < > P 18341:19336(995)
ack 841 win 31856 <nop,nop,timestamp 14982526 24882662> (DF)
12:43:43.984673 eth0 > > . 841:841(0) ack
19336 win 31856 <nop,nop,timestamp 24882797 14982525> (DF)

I never used tcpdump before and I wasn't sure what you wanted, so I hope this
output is helpful.

Comment 33

18 years ago
Presumably, Mozilla reopens and rereads the GIF file from cache every time it 
loops. Thus it fails to work correctly if the image was not cached. This form 
of the bug also exists in NS4. See also bug 40867.

I set up a test page with an uncacheable GIF at The test does not directly indicate 
when a reload has occurred, so you'll have to monitor your own network activity.

Comment 34

18 years ago
Unnecessary server pounding is still happening in Netscape 6.0PR3 under (at
least) Windows 2000.

I've got 196 hits in a row, five seconds apart (the exact time of the
animation), all returning status 200, from one user of "Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; m18) Gecko/20000929 Netscape6/6.0b3", and a smaller
number from a different IP address with the same user agent.

It's possible that other platforms may have this problem too; all I have is what
my httpd logs show me, and there's a lack of similar pounding from other 6.0b3
users with Win9x or Linux.  A test by a friend with the 20001002 build also
failed to turn up this problem.

nsbeta3 keyword, bug still present in PR3.  Please reopen.
Resolution: FIXED → ---

Comment 35

18 years ago
Thanks for the info. I thought we had this one licked.
I'll see whats changed in netlib code, or netcache code.

Comment 36

18 years ago
Could you tell me what your prefs settings for the cache
are? Verify once per session? Verify every time? Never?



18 years ago
Target Milestone: --- → Future


18 years ago
Blocks: 61479

Comment 37

17 years ago
This bug was marked to be fixed in a previous milestone but it didn't get fixed 
properly. Nominated for beta1.
Keywords: nsbeta1


17 years ago
Blocks: 66959

Comment 38

17 years ago
I get a lot of disk activity when visiting sites with animated GIFs (such as, using the most recent 0.8 build (2001021502) on Mac.

Comment 39

17 years ago
I would get that the disk activity is due to refetching each animated GIF from 
the disk cache for *each* animation loop...

Currently, imagelib does not cache animated GIF images...  This means that the 
URI must be refetched for each cycle.  On a good day, the GIF image will be in 
the disk cache...

Comment 40

17 years ago
The imglib should get the compressed data from the
necko cache. When the new cache changes land, we'll test
this again.
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: Future → mozilla0.9

Comment 41

17 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov

Comment 42

17 years ago
Just found an excellent test case for this (I think) -

Comment 43

17 years ago

I'm using 0.81 release for windows (build 2001032319) and am seeing the problem
previously reported in the thread: animated GIFs are continuously reloaded over
the network.  I have "Verify.." as "Once per session".  Any animated gif seems
to work.  tcpdump/tcpflow seem to show that the entire gif is getting
transmitted over and over (200 response) every time I've tried it.

Comment 44

17 years ago
Would you mind trying again with a recent nightly build?  Since 0.8.1, mozilla
has replaced the cache and the image rendering library.

Comment 45

17 years ago
Wow, that was fast... yes, with build 2001040604 the problem seems to have been
resolved.  Thanks.

Comment 46

17 years ago
Yep, wfm with my test case as well.

Comment 47

17 years ago
marking wfm per comments
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 48

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