Closed Bug 5030 Opened 26 years ago Closed 25 years ago

[BETA] Animated GIFs hit server (200) every time they loop

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Crysgem, Assigned: pnunn)

References

(
URL
)

Details

(Whiteboard: [PDT-]Dependent on network cache.(enabled).)

Attachments

(1 file)

Load this GIF and watch Mozilla send infinite requests to the server
(deleted), image/gif
Details
Upon completing the loading and rendering of the cited URL, the beast does not cease it's requests for the various .GIFs (which have already been loaded and displayed)... it will cycle through two or three requests (that have already been completed), continually flashing messages of the form "http://mad.mozilla.org/image.gif: stop" and "Connect: contacting host: http://sad.mozilla.org/" and "Connect: http://bad.mozilla.org/subdir/pubdir/image.gif 127.123.123.1:2353" to the status bar, so establishing several persistent connections (~10, on at least three occasions with a freshly booted system). This rudeness was assessed with MS' soi-disant "netstat" kluge, which of course was driven quite mad by the fearful sight, proceeding in it's fevered panic to consume all spare CPU power, and refusing to die like any good MS networking afterthought... (April 12 Mozilla.org Nightly Build)
Assignee: rickg → troy
Component: Viewer App → Layout
QA Contact: 3853 → 4144
Crysgem, could you please read: http://www.mozilla.org/quality/bug-writing-guidelines.html Was this with Apprunner or Viewer? Which build? Need more specific info to help you please.
Assignee: troy → pnunn
Component: Layout → ImageLib
Pam, here's a small subset of the HTML that shows the animated gif. Are we in fact establishing a new network connection for each frame? <html> <head> <title>Dispearing bg image</title> </head> <body> <img width=468 height=60 src="http://adserver.imaginemedia.com/cgi-bin/accipiter/AdServer.exe/AREA=PC.ARS TECHNICA"> </body> </html>
Status: NEW → ASSIGNED
re: the html fragment:: Nope. Not with the 04-20-99 build. Everything looks fine with the animated gif. Let me try another idea. -pn
I'm not seeing weird behaviour with animated gifs. Using TracePlus I can see the data pass betwn client and server and the image is not repulled for each display cycle. Perhaps this has been fixed by other checkins. Can anyone verify? -pn changed, but i.
The behavior in question, namely the repeated obsessive connection establishment (that has the sound of a politician, doesn't it?), has *NOT* been resolved in a more recent build (4-20-1999), on this machine leastwise. The circumstances are alike - Windows 98, Viewer (NOT Apprunner), same Internet site.
I'm stomping around in netlib. This may take awhile to track down. -pn
Target Milestone: M6
I'm not seeing crazy behavior here. The browser does check with the server for every full cycle to see if the version on the server has been modified. It should do this. Otherwise, many vidcams wouldn't work. It is not pulling the image data across the server every cycle. It sees the image file has not been modified, and it can use the locally cached (network cache) version. and it does. Show me what you are using to determine the browser is reloading the image data across the server. -pn
from traceplus log: 16:22:59.930 |HTTP/1.1 304 Use local copy |Server: Netscape-Enterprise/3.5.1C |Date: Mon, 26 Apr 1999 23:26:31 GMT |Link: <http://ganges.imagine-inc.com/maxpc/house/MPC Network House Ad.gif?PageSe |rvices>; rel="PageServices" 16:23:10.114 |GET /maxpc/house/MPC%20Network%20House%20Ad.gif HTTP/1.1 |If-Modified-Since: Fri, 26 Mar 1999 21:09:25 GMT; length=14581 |Connection: Keep-Alive |User-Agent: Mozilla/5.0 [en] (Win95; I) |Pragma: no-cache |Host: ganges.imagine-inc.com |Accept: text/html, text/xml, image/png, image/gif, image/x-xbitmap, image/jpeg, |image/pjpeg, */* |Accept-Encoding: gzip 16:23:10.144 |HTTP/1.1 304 Use local copy |Server: Netscape-Enterprise/3.5.1C |Date: Mon, 26 Apr 1999 23:26:41 GMT |Link: <http://ganges.imagine-inc.com/maxpc/house/MPC Network House Ad.gif?PageSe |rvices>; rel="PageServices"
I utilized no more than the ever-active status bar, the taskbar BPS count and the netstat command initially. The page rendering (with images) is completed and the throbber stills, but the bytecount increases substantially (even when Mozilla is the only Internet-aware process executing), the status bar continues to speak of newly obtained data, and netstat will not relent it's indication that several connections in varying states (CLOSE_WAIT, TIME_WAIT, FIN_WAIT_2, and the hateful ESTABLISHED) remain... so long as Viewer displays this page. Hanging up the modem causes Mozilla to intemperately demand connection re-establishment (again, determined on a system on which Mozilla was the only network-capable process running) - and disabling the connection causes the images (the two banner images on the CNN page - see below) to disappear, their ALT text data instead being displayed. The beast *IS* continually seeking data, on this system, leastwise. As it is so cordially asked, only a packet sniffer's output and netstat were employed to determine that the data is repeatedly requested (and sent). The shareware version of Traceplus does not enable logging - I cannot alas match. It may interest the module owner to note that this behavior also afflicts http://www.cnn.com/TECH/computing/9904/28/linux.ent.idg/.
It is not DOWNLOADING data. It is insisting on testing the server to see if the data has been modified. but, yes, it is annoying. Gagan and I will fix it to be less annoying. Necko (Son of Netlib) should be landing relatively soon. Gagan said that trying to address this before the landing is wasted effort. Despair not. but whine not too. at least not until Necko lands. Then the whining may begin. -pn
*** Bug 6006 has been marked as a duplicate of this bug. ***
Target Milestone: M6 → M8
*** Bug 7980 has been marked as a duplicate of this bug. ***
*** Bug 7981 has been marked as a duplicate of this bug. ***
To see this bug in action go here > http://lavender.fortunecity.com/brasco/366/ , then click on Pikachu in the left frame, it loads a page with many gifs, lots of then animated, and basically the animated ones take forever to load and many of the static ones seem to never load or finish loading do to this problem.
Ach... is this platform of many shoutings a duplicate of Bug 2860?
*** Bug 1885 has been marked as a duplicate of this bug. ***
Summary: Insane port/request behavior → Animated GIFs hit server (304) every time they loop
[Gave the bug a more accessible title, so that folks doing queries are more likely to find it. Will request that Jan add it to the most common Mozilla bug list, too, if it isn't already on it.]
QA Contact: petersen → elig
[Also, QA Assigning to self, as it's an ImageLib bug.]
I had already notified Herr Leger, elig@netscape.com... retitling, excellent notion. Should Bug 2860 be judged duplicate of this report, or vice-versa?
Yup, thanks. actually...it was already on the most-frequent-bugs list...I just missed it! Re: 2860. Good point. I suspect there may be a nun here (well, Pam Nunn) who could make that call...? ;)
Well, strangely enough bug#2860 maybe a different animal, though the symptoms are similar. Let's leave it as a separate bug. And since its origin was in the old code base, all bets are off as to its status. -pn
Eli Goldberg and Pat Nunn, it is a positive pleasure to deal with such engineers as yourselves. You are positively pleasant and efficient as compared with certain others, such as rickg@netscape.com and cpratt@netscape.com. Let's see a dominance of chicks at Netscape! I am certain that 't'is no coincidence.
Target Milestone: M8 → M9
This has a strong dependency on the necko landing. -pn
Tried above link and other sites with animated Gifs. Page seems to finish loading properley without the loops like used to.. 1999080312 Build
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Let's close this bug quick! hip hip hurrah for Necko. -pn
Status: RESOLVED → REOPENED
Re-opening. Using the 1999080908 Mac OS build, my server is receiving a 200 request, every 2 seconds, while the animated GIF is animating.
Resolution: FIXED → ---
(err, specifically, the animation takes 2 seconds to iterate, so the 200 request occurs each time the animation cycles.)
I would imagine this is because the cache is not implemented in the mac builds..... Correct me if I'm wrong, Gagan. -pn
Doh...good point, I'll check.
Hmm...same behavior on today's Windows build, so I also defer to Gagan.
Agreed that there is no network cache as yet. But shouldn't the animated gifs be in imagelib cache?
Contrary to common sense, no. Animated images are not stored in the imglib cache. They are redecoded from the network cache. (and use the reload policy where only the netlib cache is used.) I'd like to change this, but not now. I'm having trouble seeing the code path with necko. Looking at it yesterday, the imglib requests the info from the netlib cache. If that cache doesn't exist, I should see an error....but I don't. TracePlus shows the request going to the server. I'll be working on this one today. -pn
-> m10
Whiteboard: Dependent on network cache.(enabled).
Target Milestone: M10 → M11
Necko has landed. but the cache is not enabled. Until the cache is enabled, animated images will go back to the server. When net cache is enabled (~m11), add 'SetReloadPolicy(aReloadMethod); at line 527 in mozilla/gfx/src/nsImageNetContextAsync.cpp. For testing, put break at mozilla/netwerk/http/src/nsHTTPRequest.cpp, line 217. Can trace http GETs to the server here. Buffering the decoded image may take up alot of memory. There would be double buffering (netlib (compressed) & imaglib (decompressed)). Being able to set cache to live in ram might be the best way to make anim's more efficient.
Target Milestone: M11 → M15
*** Bug 14248 has been marked as a duplicate of this bug. ***
Summary: Animated GIFs hit server (304) every time they loop → Animated GIFs hit server (200) every time they loop
Updated subject per behavior of 1999.09.22 build.
Summary: Animated GIFs hit server (200) every time they loop → [BETA] Animated GIFs hit server (200) every time they loop
At risk of rampant flamage, I'm marking this bug as [BETA], and suggest that it be moved to an earlier milestone. Here's why: * There may be a million or so people using whatever Beta build is shipped * We're now doing a full 200 request (rather than 304) every image iteration. * Most ISP-based have a per-day quota of how much can be downloaded. Assuming a 200 MB quota, one user who leaves their browser pointing to a page with an animated GIF could bring down the site within 2-3 hours. (This happened to me yesterday, in which I used up 35% of my daily 200 MB Best quota within an hour.)
Grrr...make that: * Most ISP-based Webmasters have a per-day quota of how much can be downloaded from their site.
cc'ing fur.
Depends on: 14050
Summary: [BETA] Animated GIFs hit server (200) every time they loop → [DOGFOOD][BETA] Animated GIFs hit server (200) every time they loop
Target Milestone: M15 → M11
Whiteboard: Dependent on network cache.(enabled). → [PDT-] Dependent on network cache.(enabled).
PDT says this is performance, and not a use-stopper.
Whiteboard: [PDT-] Dependent on network cache.(enabled). → Dependent on network cache.(enabled).
Requesting PDT re-evaluation. In particular, please review the 09/23/99 comments made by self. By publishing a beta release with this bug left open, we will be BRINGING DOWN quota'd web sites that use animated GIFs every time a web surfer goes to the page, and then trots off to do something else for a few hours, without closing their browser window. That's a common use case, and the resulting "Your web browser shut down my web site" is a non-trivial result.
Whiteboard: Dependent on network cache.(enabled). → Dependent on network cache.(enabled). [PDT-]
Agreed, must be fixed by beta.
[left voice mail for jar --- confused why this is re-marked as PDT- when agreed as a beta must-fix.]
Whiteboard: Dependent on network cache.(enabled). [PDT-] → [PDT-]Dependent on network cache.(enabled).
dogfood is not Beta. We need to do minimal everyday work for dogfood. Thus this is PDT-
Target Milestone: M11 → M12
pushing to m12, awaiting cache.
*** Bug 17299 has been marked as a duplicate of this bug. ***
Gotta do something about this bug. Attaching a very small animated GIF. Monitored through proxy - mozilla is requesting for this image every second or so from the server. Neither IE5 nor NS4.x exibit this behaviour.
Thanks for your input. We are aware of the problem. No more test urls needed. Fixing this depends on the completion of some work in netlib..... -pn
This bug requires the network cache. Making a guess that the cache will be enabled in m15. -pn
Summary: [DOGFOOD][BETA] Animated GIFs hit server (200) every time they loop → [BETA] Animated GIFs hit server (200) every time they loop
Target Milestone: M12 → M15
Depends on: 8305
No longer depends on: 14050
Depends on: 21036
Status: REOPENED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 21036 ***
No longer depends on: 21036
Status: RESOLVED → VERIFIED
Verified as duplicate. Left note in 21036 to check this bug as part of its verification.
*** Bug 17299 has been marked as a duplicate of this bug. ***
*** Bug 22191 has been marked as a duplicate of this bug. ***
I'm re-opening this bug, rather than making 21036 an uber-bug that will never die. Specifically, when I display an animated GIF using yesterday morning's Seamonkey build, I receive two hits on the web server: 208.12.39.157 - - [15/FEB/2000:09:09:41 -0800] "GET /7upcan.gif HTTP/1.0" 200 33850 208.12.39.157 - - [15/FEB/2000:09:09:41 -0800] "GET /7upcan.gif HTTP/1.0" 200 33850 However, when I display the same image using Communicator 4.7 on the same server, I'm only seeing one hit: 208.12.39.157 - - [15/FEB/2000:09:10:28 -0800] "GET /7upcan.gif HTTP/1.0" 200 33850 Is this intentional, Pam, or should this be a separate bug? (and if so, would it go to you or to Gagan?) Thanks!
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(This behavior occurs on all 3 primary platforms, BTW.)
Per request from pnunn (thanks!), marking this bug as verified and opening new bug for the corner case.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
Reopening. Mozilla now repeats the request again. Observed on 2000080508 nightly build on Windows 2000.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 48546 has been marked as a duplicate of this bug. ***
*** Bug 48754 has been marked as a duplicate of this bug. ***
I'm closing bug #5030 and reopening #48546. Bug#5030 was closed 6 months ago. After 6 months, a similiar symptom is apt to have a very different cause.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verifying fixed per last post. win98 1E 2000092808
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: