Closed Bug 48546 Opened 25 years ago Closed 24 years ago

Too many progress messages generated for animated GIFs

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9

People

(Reporter: hyatt, Assigned: pavlov)

References

(
URL
)

Details

Attachments

(1 file)

patch file...
10.16 KB, patch
Details | Diff | Splinter Review
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.
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
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
*** This bug has been marked as a duplicate of 5030 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 48754 has been marked as a duplicate of this bug. ***
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.
Target Milestone: --- → Future
*** Bug 49194 has been marked as a duplicate of this bug. ***
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
*** Bug 49234 has been marked as a duplicate of this bug. ***
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 cnn.com. 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 repeat... 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.
This is one of the problems we have been discussing with the image cache. cc'ing relevant people and making this a plus.
Status: REOPENED → ASSIGNED
Whiteboard: [nsbeta3+]
Target Milestone: Future → ---
*** Bug 49757 has been marked as a duplicate of this bug. ***
This seems to be fixed in Linux 2000082121. Can anyone confirm?
Problem still exists in Linux 2000-08-21-21.
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 way. -p
Assignee: gagan → pnunn
Status: ASSIGNED → NEW
Checkin for bug#20110 fixed this bug. -p
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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 cnn.com. Do I misunderstand the bug? I think this need reopening....
I am not seeing this problem anymore on Linux 2000082121...
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 opens...
Attached patch patch file... — — Splinter Review
Rick: I'm asking Neeti to scan the patch. I'm a novice when it comes to necko cache. -p
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. -p
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? -P
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 problem...
ok. thanks for the clarification. onward....
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).
I'm no longer seeing an if-modified-since request / 304 response for animated GIFs... 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
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. -p
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
It's fixed: linux 2000090208. tcpdump show no reload of animated gifs through the net.
*** Bug 51529 has been marked as a duplicate of this bug. ***
(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. ./run-mozilla.sh 3. load url: http://bluesnews.com/miscimages/banners/m_blu_butt.gif (some) output from tcpdump: blank lines added by me to emphasis time lapses 192.168.1.1 is my address on the local net. 12:43:28.379896 eth0 > 192.168.1.1.4084 > 205.229.73.2.www: P 193385651:193385931(280) ack 7572848 win 31856 <nop,nop,timestamp 24881236 62268601> (DF) 12:43:28.534159 eth0 > 192.168.1.1.4084 > 205.229.73.2.www: F 280:280(0) ack 1 win 31856 <nop,nop,timestamp 24881252 62268601> (DF) 12:43:28.536170 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: S 412048126:412048126(0) win 32120 <mss 1460,sackOK,timestamp 24881252 0,nop,wscale 0> (DF) 12:43:28.660858 eth0 < 205.229.73.2.www > 192.168.1.1.4090: S 237742916:237742916(0) ack 412048127 win 32120 <mss 1460,sackOK,timestamp 14981110 24881252,nop,wscale 0> (DF) 12:43:28.661008 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 1:1(0) ack 1 win 32120 <nop,nop,timestamp 24881264 14981110> (DF) 12:43:28.661388 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: P 1:281(280) ack 1 win 32120 <nop,nop,timestamp 24881264 14981110> (DF) 12:43:28.830979 eth0 < 205.229.73.2.www > 192.168.1.1.4090: . 1:1(0) ack 281 win 31856 <nop,nop,timestamp 14981128 24881264> (DF) 12:43:29.152418 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 1:1449(1448) ack 281 win 31856 <nop,nop,timestamp 14981132 24881264> (DF) 12:43:29.152527 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 281:281(0) ack 1449 win 31856 <nop,nop,timestamp 24881314 14981132> (DF) 12:43:29.402650 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 1449:2897(1448) ack 281 win 31856 <nop,nop,timestamp 14981132 24881264> (DF) 12:43:29.652235 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 281:281(0) ack 2897 win 31856 <nop,nop,timestamp 24881364 14981132> (DF) 12:43:29.662924 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 2897:4345(1448) ack 281 win 31856 <nop,nop,timestamp 14981171 24881314> (DF) 12:43:29.682261 eth0 > 192.168.1.1.4084 > 205.229.73.2.www: FP 0:280(280) ack 1 win 31856 <nop,nop,timestamp 24881367 62268601> (DF) 12:43:29.923048 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 4345:5793(1448) ack 281 win 31856 <nop,nop,timestamp 14981171 24881314> (DF) 12:43:29.923191 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 281:281(0) ack 5793 win 31856 <nop,nop,timestamp 24881391 14981171> (DF) 12:43:30.032465 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 5793:6446(653) ack 281 win 31856 <nop,nop,timestamp 14981220 24881364> (DF) 12:43:30.052201 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 281:281(0) ack 6446 win 31856 <nop,nop,timestamp 24881404 14981220> (DF) 12:43:32.302185 eth0 > 192.168.1.1.4084 > 205.229.73.2.www: FP 0:280(280) ack 1 win 31856 <nop,nop,timestamp 24881629 62268601> (DF) 12:43:35.895205 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: P 281:561(280) ack 6446 win 31856 <nop,nop,timestamp 24881988 14981220> (DF) 12:43:36.338553 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 6446:7894(1448) ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF) 12:43:36.598856 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 7894:9342(1448) ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF) 12:43:36.598972 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 561:561(0) ack 9342 win 31856 <nop,nop,timestamp 24882058 14981851> (DF) 12:43:36.788610 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 9342:10448(1106) ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF) 12:43:37.049842 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 10448:11896(1448) ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF) 12:43:37.218856 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 11896:12891(995) ack 561 win 31856 <nop,nop,timestamp 14981851 24881988> (DF) 12:43:37.218951 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 561:561(0) ack 12891 win 31856 <nop,nop,timestamp 24882120 14981851> (DF) 12:43:37.542185 eth0 > 192.168.1.1.4084 > 205.229.73.2.www: FP 0:280(280) ack 1 win 31856 <nop,nop,timestamp 24882153 62268601> (DF) 12:43:42.635137 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: P 561:841(280) ack 12891 win 31856 <nop,nop,timestamp 24882662 14981851> (DF) 12:43:43.094326 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 12891:14339(1448) ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF) 12:43:43.354586 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 14339:15787(1448) ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF) 12:43:43.354703 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 841:841(0) ack 15787 win 31856 <nop,nop,timestamp 24882734 14982525> (DF) 12:43:43.554334 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 15787:16893(1106) ack 841 win 31856 <nop,nop,timestamp 14982525 24882662> (DF) 12:43:43.804910 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 16893:18341(1448) ack 841 win 31856 <nop,nop,timestamp 14982526 24882662> (DF) 12:43:43.984614 eth0 < 205.229.73.2.www > 192.168.1.1.4090: P 18341:19336(995) ack 841 win 31856 <nop,nop,timestamp 14982526 24882662> (DF) 12:43:43.984673 eth0 > 192.168.1.1.4090 > 205.229.73.2.www: . 841:841(0) ack 19336 win 31856 <nop,nop,timestamp 24882797 14982525> (DF) etc... I never used tcpdump before and I wasn't sure what you wanted, so I hope this output is helpful.
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 http://home.mieweb.com/jason/testbed/anim/. The test does not directly indicate when a reload has occurred, so you'll have to monitor your own network activity.
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thanks for the info. I thought we had this one licked. I'll see whats changed in netlib code, or netcache code. -p
Doug: Could you tell me what your prefs settings for the cache are? Verify once per session? Verify every time? Never? thnx, pn
Target Milestone: --- → Future
Blocks: 61479
This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.
Keywords: nsbeta1
Blocks: 66959
I get a lot of disk activity when visiting sites with animated GIFs (such as http://www.salon.com/), using the most recent 0.8 build (2001021502) on Mac.
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...
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
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: REOPENED → NEW
Just found an excellent test case for this (I think) - http://yahoo.bulldogresearch.com/analyst_as.asp?ID=120089&T=E
Hi, 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.
Would you mind trying again with a recent nightly build? Since 0.8.1, mozilla has replaced the cache and the image rendering library.
Wow, that was fast... yes, with build 2001040604 the problem seems to have been resolved. Thanks.
Yep, wfm with my test case as well.
marking wfm per comments
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
verified
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: