After reaching the end of their display cycle, animated gifs seem to be reloaded from the network, causing unnecessary network traffic. They don't seem to be cached at all.

Setting all current Open/Normal to M4.

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

*** Bug 2493 has been marked as a duplicate of this bug. ***

I think Pam has fixed this? Or was it nisheeth? Assigning to Pam, she would know!

lets mark it fixed and get it regressed. if its still a bug reopen.

*** Bug 4028 has been marked as a duplicate of this bug. ***

This doesn't appear fixed to me. I don't have a debugger to confirm it, but if I unplug my network cable, the gifs stop animating. Plug it back in, and alls well again. Not an M4 stopper though, moving to M5.

animated gifs do redecode for each full cycle, but they use (or should use) the data from the network cache. I will check it. Maybe netlib is checking the last-modified field from the server? -pn

this bug looks like a duplicate of 4028. I'm marking as such. *** This bug has been marked as a duplicate of 4028 ***

ok. 4028 is already marked as the duplicate. Be aware that #4028 has more data on problem than this bug report. I'm reopening this one. sheeesh. -pn

The browser does send a request to make sure the image has not changed since it last loaded it. but if the image has not changed, it doesn't load it from the server, it loads it from the network cache. I've verified this by using traceplus to watch what is passed between browser and server. If you question that the server should be contacted at all, we have to address this as a design question. Intended behavior. The browser does work as the spec requests. -pn

Well, I'm going to re-open and assign to gagan, perhaps he is all over this or knows what the right thing to do is. The problem is we are going back to the originating server and checking if the animated gif has changed each time it cycles thru it's frames. This seems like a bad thing to do to me - it seriously hurts performance. We did not do this on 4.51. Basically, the user is not hitting reload, why should we go back and check if there is something new just because it's an animated gif?

re-assigning to Gagan and moving to M6

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

Putting on [Perf] radar

Note: neither IE nor Communicator 4.x behave this way - they do not check to see if the file has changed on the server.

I agree with Paul here. Animated gifs (at the end of their cycle) should not be rechecked from network cache unless the reload policy insists checking it from server again. But they should exist in the image cache. I think it should be fairly easy to detect animating gifs and set them to reload without checking from the network. I believe that this would be somewhere in imagelib's cache. Assigning back to Pam.

I believe the problem is the document is not sending the reload policy through the image request. I will track this down once I get my features checked in. But, for all versions of 4.x communicator, animated images are redecoded from the netlib cache data. We may want to change that behavior in the future. For now, lets get the behaviour that is in 4.x working properly. Whether netlib wants to test the 'freshness' of the data, is a matter of the reload policy being passed properly through the various levels (views, doc, image request, etc.). -pn

This is one of a number of reloaded/cache/animated image issues, all of which read much alike... namely, this is at the least tangentially related to Bug 5030 and Bug 2860 (if not duplicatatory).

Is a duplicate. -pn *** This bug has been marked as a duplicate of 5030 ***

I concur.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.