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

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Volker Moell]

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: <[e-mail]> reports
"Loops once" works as expected. "Never" is like "Loops once".

Comment 1

[Volker Moell]

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

Comment 2

[Matthias Versen [:Matti]]

wfm with win2k build 20030322

Comment 3

[Volker Moell]

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

Comment 4

[R.K.Aa.]

dup of bug 103166?

Comment 5

[Jesiah S]

WFM LInux 2003032305 

Comment 6

[uamjet602]

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.

Comment 7

[Sébastien Delahaye]

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

Comment 8

[Jim Dunn]

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

Comment 9

[Volker Moell]

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

[Carl Hage]

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

Comment 11

[Stefan Borggraefe]

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

Comment 12

[Stefan Borggraefe]

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. ;-)

Comment 13

[John Stilian]

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

[Stefan Borggraefe]

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.

Comment 15

[Jim Dunn]

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

[John Stilian]

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

[Stefan Borggraefe]

Another gif picture that still animates:

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

Tested with a CVS-build ofrom today on Linux.

Comment 18

[Jim Dunn]

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

[Stefan Borggraefe]

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.

Comment 20

[Volker Moell]

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

[David Crick]

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)

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

>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)

Comment 23

[Boris Zbarsky [:bzbarsky]]

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 24

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

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 27

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v2

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 29

[Boris Zbarsky [:bzbarsky]]

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.

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 122425 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.4b

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[Boris Zbarsky [:bzbarsky]]

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