Animated image rotates although "Animate images should loop ... [X] never" is marked

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: volker, Assigned: jdunn)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323

The GIF banner http://www.klografx.net/qiv/banner.gif rotates although I marked
"Animate images should loop ... [X] never"

Reproducible: Always

Steps to Reproduce:
1. open URL
2. look 

Actual Results:  
image rotates

Expected Results:  
don't rotate

Message-ID: <3E7F4065.3090503@hfigge.myfqdn.de> reports
"Loops once" works as expected. "Never" is like "Loops once".
(Reporter)

Comment 1

16 years ago
*** Bug 199043 has been marked as a duplicate of this bug. ***
wfm with win2k build 20030322
Component: Image: GFX → ImageLib
(Reporter)

Comment 3

16 years ago
Qualifying reproducibility to "sometimes": After rebooting my Linux the banner
does not rotate any longer (i.e. it works as expected).

Comment 4

16 years ago
dup of bug 103166?

Comment 5

16 years ago
WFM LInux 2003032305 

Comment 6

16 years ago
There definitely is a regression here, having to do with how the image is loaded.

I noticed the same problem on http://www.chicon.nl/strd-img/new.gif .

Steps to reproduce:
- set looping to never in the configuration panel
- load the image in a new window, and then press shift-reload
- notice correct behaviour
- click the url bar and press enter to reload from cache
- notice the image looping (incorrect behaviour)

-> confirmed linux 2003032517

note that this is not the same as bug 103166 which is about images in certain
locations being animated (like in a table background). The images in this bug
rotate even if you load them in a separate window.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

16 years ago
*** Bug 200459 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

16 years ago
hmmmm, I can't reproduce on linux or win2k using 1.4a release build (and other
random builds)
(Reporter)

Comment 9

16 years ago
In the meantime I saw other sites with rotating images.  Until a few weks ago
the did not rotate with my "never" settings. But from about middle of march 2003
some images rotate sometimes. It's not reproducable (any longer).
Another site is http://www.heise.de/newsticker/. Here are several rotating
images.  Normally they won't rotate on my settings, but about once per day they do.

Comment 10

16 years ago
This appears to be a duplicate of bugs 200557 and 103166. This might
also affect bugs where image animation stops (bug 192631). 

Comment 11

16 years ago
*** Bug 200557 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
I also see this bug with Windows XP and Build 2003041416. Some GIFs that are
animated although I have activated "Animate images should loop ... [X] never":

resource:///res/samples/test10.html
http://www.n-tv.de/images/200212/3047132_ticker9.gif
http://www.greencofinancial.com/images/logo.gif (from Bug 200557)

The gearwheels in resource:///res/samples/test10.html strangely stop animating
after a few minutes.

This is a recent regression. Otherwise I would have noticed this before, because
I hate those distracting anim-GIFs. ;-)
Blocks: 119597
Keywords: regression
OS: Linux → All
Hardware: PC → All

Comment 13

16 years ago
So, I haven't seen any discussion of this bug being closed, but I haven't seen
it manifested in the 20030422 builds. Has a fix been checked in or another bug
squashed tha took this one with it?

Comment 14

16 years ago
For me this works fine again for all examples given in this bug and the dupes
except for resource:///res/samples/test10.html

Tested with build 2003042208 and Windows XP.
(Assignee)

Comment 15

16 years ago
Interesting.  If I download gear1.gif and load it locally (file:) or 
put it on a website (http:), it honors the loop flag.  If I load it with
file: from the mozilla install site 
(file:///C:/Program%20Files/mozilla.org/moz_4_22/res/samples/gear1.gif)
it honors the loop flag
HOWEVER, if I load it via the res: (resource:///res/samples/gear1.gif)
it doesn't... 

very interesting!

Comment 16

16 years ago
Well, seems I spoke too soon. Some GIFs that used to animate no longer do, but
I've seen three others that continue to animate.

Comment 17

16 years ago
Another gif picture that still animates:

http://www.n-tv.de/shared/symbole/chataktuell.gif

Tested with a CVS-build ofrom today on Linux.
(Assignee)

Comment 18

16 years ago
Using my own build from today on win2k and linux
http://www.n-tv.de/shared/symbole/chataktuell.gif
http://www.n-tv.de/images/200212/3047132_ticker9.gif
http://www.greencofinancial.com/images/logo.gif 
None of these loop if I say Loop Never on either machine.

Stefan, can you create a New Profile.  Select Loop Never in that
and retry with chataktuell.gif?  Thanks

Comment 19

16 years ago
http://www.n-tv.de/shared/symbole/chataktuell.gif doesn't animate anymore with a
CVS build from today on Linux. I'm using the same profile as when I wrote
comment #17 but it works now. Strange.
(Reporter)

Comment 20

16 years ago
On CVS releast from 2003-03-26 rarely some images still rotate (here the top
banner from http://www.heise.de/newsticker/).  In my opinion there is some kind
of random in the problem and it does concern to all kinds of animated GIF's, not
just to special ones.

Comment 21

16 years ago
Surely enough people have confirmed this bug now?

It seems fairly obvious that it is a regression,
starting around mid March, i.e. after 1.3 release.

Shouldn't the 1.4 code be compared to the 1.3 code
or (at least if this is still dragging on nearing
the time of the 1.4 release!) just replace the
ImageLib component with the older, working version?!

(btw, the bug still occurs even when JS is disabled)
>just replace the
>ImageLib component with the older, working version?!

uh...
the idea is bad in general (because then other bugs would come back), and is not
even possible (APIs used by imagelib have changed)
This is a regression from bug 83774.  The problem is that SetAnimationMode must
be called explicitly by clients of libpr0n.  All well and good, but it's called
in nsImageFrame::OnStartContainer.  If the image is loading from cache as the
page is loaded, it can blow through all the notifications before the image frame
is constructed, so that nsImageFrame::OnStartContainer never gets called.
Possible solutions:

1)  Move the animation mode stuff down into libpr0n (I bet pav would love this;
    also see solution 2 and its problems).
2)  Move the animation mode setting to nsImageLoadingContent::OnStartContainer
    (note that this could be somewhat expensive since we can't just get the pref
    from the prescontext then... is the animation mode really per-presentation,
    or is it per document?  Or just global?).
3)  Add code in nsImageFrame::Init() to set the animation mode if the current
    request already has an image container.

Solution #3 is easiest in the short term; in the long term we need to decide
what the image animation stuff should really be doing and actually document it
so we don't have to guess anymore... ;)

I won't be able to get to this for a week at least, so if we want this for 1.4
(we do), could someone do it?  biesi?
Comment on attachment 122412 [details] [diff] [review]
patch

Um... how about not relying on currentLoadStatus and just setting the animation
mode if we have a container?  A lot of time can pass between container creation
and the status becoming STATUS_LOAD_COMPLETE
Attachment #122412 - Flags: review?(bz-bugspam) → review-
Well, part of the reason was speed - testing a bit is faster than getting the
image container.

but sure, I'll make that change
Comment on attachment 122425 [details] [diff] [review]
patch v2

oh, hm, I see your point... if there was a partial load, my original patch
wouldn't have worked
Attachment #122425 - Flags: review?(bz-bugspam)
Comment on attachment 122425 [details] [diff] [review]
patch v2

s/complete image/image container/, maybe? It's not complete by any means....

The rest looks fine.
Attachment #122425 - Flags: superreview+
Attachment #122425 - Flags: review?(bz-bugspam)
Attachment #122425 - Flags: review+
Comment on attachment 122425 [details] [diff] [review]
patch v2

This patch makes the [x] never animate images preference work again reliably.
It would be nice to fix this for 1.4b, and the patch is quite small and not
very risky.

bz: err. I will s/complete//, that's a leftover from the older patch
Attachment #122425 - Flags: approval1.4b?

Comment 31

16 years ago
Comment on attachment 122425 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.4b
Attachment #122425 - Flags: approval1.4b? → approval1.4b+
Checking in layout/html/base/src/nsImageFrame.cpp;
/cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v  <--  nsImageFrame.cpp
new revision: 1.279; previous revision: 1.278
done
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 204514 has been marked as a duplicate of this bug. ***
*** Bug 103166 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.