Animated gifs reloading unnecessarily

VERIFIED DUPLICATE of bug 5030

Status

()

P2
normal
VERIFIED DUPLICATE of bug 5030
20 years ago
17 years ago

People

(Reporter: michael.j.lowe, Assigned: pnunn)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Perf])

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Assignee: michaelp → gagan
Component: Rendering → Networking Library

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
Setting all current Open/Normal to M4.

Comment 2

20 years ago
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. ***

Updated

20 years ago
Assignee: gagan → pnunn
Status: ASSIGNED → NEW

Comment 4

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

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 5

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

Comment 6

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

Updated

20 years ago
Status: RESOLVED → REOPENED
Target Milestone: M4 → M5

Comment 7

20 years ago
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.
(Assignee)

Comment 8

20 years ago
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
(Assignee)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: FIXED → DUPLICATE
(Assignee)

Comment 9

20 years ago
this bug looks like a duplicate of 4028. I'm marking as such.

*** This bug has been marked as a duplicate of 4028 ***
(Assignee)

Updated

20 years ago
Status: RESOLVED → REOPENED
(Assignee)

Comment 10

20 years ago
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
(Assignee)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: DUPLICATE → WORKSFORME
(Assignee)

Comment 11

20 years ago
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

Updated

20 years ago
Status: RESOLVED → REOPENED

Updated

20 years ago
Assignee: pnunn → gagan
Status: REOPENED → NEW
Target Milestone: M5 → M6

Updated

20 years ago
Resolution: WORKSFORME → ---

Comment 12

20 years ago
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?

Comment 13

20 years ago
re-assigning to Gagan and moving to M6

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 14

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

Updated

20 years ago
Whiteboard: [Perf]

Comment 15

20 years ago
Putting on [Perf] radar

Comment 16

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

Updated

20 years ago
Assignee: gagan → pnunn
Status: ASSIGNED → NEW

Comment 17

20 years ago
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.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 18

20 years ago
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

Comment 19

20 years ago
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).
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 20

20 years ago
Is a duplicate.
-pn

*** This bug has been marked as a duplicate of 5030 ***

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 21

20 years ago
I concur.

Comment 22

20 years ago
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. ;-)

Comment 23

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

Updated

17 years ago
Component: Networking → ImageLib
You need to log in before you can comment on or make changes to this bug.